Welcome to

the CISSP
Bootcamp
Your instructor:
Michael J Shannon
CISSP #42221 / #524169,
CCNP-Security, PCNSE7,
AWS Certified Security – Specialty, Class will begin at 10:00
OpenFAIR, and A.M. Central Standard
ITIL 4 Managing Professional Time (CST)

You can view recorded sessions and download the

course documents at: http://tiny.cc/CISSP2018LIVE
Value Proposition of
Cloud Computing
• Cost savings
• Security
• Rapid elasticity and agility
• On-demand self-service
• Broad network access
• Resource pooling
• Measured services
Cloud Computing Service Types
 Cloud Deployment Models

• Private - Deployed within the organization by the organization for the organization –
can be on-premises or hosted
• Public - Deployed by a provider within their organization for other organizations to use
• Community - Private or public but only shared between trusted groups
• Hybrid - Combination of public and/or private and/or community
Virtualization Fundamentals

A hypervisor is the software that

produces and manages a virtual
infrastructure, allowing multiple
operating systems to run and share
resources on a single physical
machine
Virtualization Fundamentals

• Host system Guest system

Type 1 Hypervisor

APP APP … APP APP …

Guest Operating System Guest Operating System …

Hypervisor

Hardware
Type 2 Hypervisor

APP APP …

Guest Operating System …

APP APP … Hypervisor

Host Operating System

Hardware
VM Sprawl
• VM sprawl occurs when the number
of VMs overwhelms the
administrator’s ability to manage
them
• Can also be “ghost IT” and
unauthorized VM software,
operating systems, and applications
• VM sprawl avoidance
• Enforce a strict process for deploying VMs
• Have a library of standard VM images
• Archive or recycle under-utilized VMs
• Implement a Virtual Machine Lifecycle
Management tool
VM Escape
• VM escape - When a process
running in the VM interacts directly
with the host OS
• VM escape protection
• Patch VMs and VM software regularly
• Only install what you need on the host
and the VMs
• Install verified and trusted applications
only
• Use strong passwords
• Control VM access
 Secure By Design

• The custom or outsourced program or application is

developed with security integrated into the entire SDLC

Application • Attackers cannot simply overcome the security controls,

even if they have white or gray box familiarity with the
Security application design
• Security by design should not rely on security by obscurity
Design
• Example: Using cloud native computing at AWS, GCP or
Azure build and run scalable applications in modern,
dynamic environments such as private and hybrid clouds
for containers, microservices, serverless functions and
immutable infrastructure
 Secure by Deployment

• The application was not developed with security integrated,

but is deployed into an environment where security was
considered in the network and system design
Application
• Developers can take advantage of infrastructure-as-code to
Security roll out well-tested application stacks
• Example: an application is deployed with air-gapped Docker
Design container separated from any untrusted networks (a private
cloud at a CSP or on-premises
• Does not include security by obscurity
 Secure by Default

• This design consideration assumes that the application is

natively secure without any modifications or additional
controls
Application
• Example: a server application has certain possible unsecure
Security functions, but they are disabled by default at deployment
based on infrastructure-as-code
Design
NIST Traditional SDLC
Software Development Life Cycle
 Waterfall Software
Development
• Sequential approach – measured in years
• Output of each phase is the input to the
next phase
• Little flexibility, not adaptable, very
predictable, testing done in the end
• Developers and customers agree on what
will be delivered early in the
development lifecycle
• This makes planning and designing more
straightforward
• Specific details, provided early in the
project, are required with this approach
Spiral Software Development
 Agile Software
Development
• For smaller projects, the concept of agile
software development is becoming a
viable alternative
• Evolutionary approach – measured in
weeks – involving collaboration between
cross-functional teams
• Very flexible, adaptable, not predictable,
with testing done during development
• Estimates (i.e. budget, schedule, etc.) get
more realistic as work progresses, because
important issues are discovered earlier
 Continuous Integration
• Continuous Integration (CI) is a development
technique that forces developers to
integrate code into a shared repository
several times a day
• Each check-in is then verified by
an automated build, allowing teams to
detect problems early
• The goal is to detect and locate
bugs and security flaws quickly
• Developers on AWS commonly use
Continuous Integration (CI) – Continuous
Deployment (CD) or CI/CD
Application Threat
Modeling
1. Decompose the application
• Get an understanding of the application and
how it interacts with external entities
• Create use cases, identify entry points, and
identify interesting assets
• Document data into a threat model document
and produce data flow diagrams (DFDs)

2. Determine and rank threats

• Use a threat categorization methodology (e.g.,
STRIDE, Trike, PASTA)

3. Define threat categories

• Determine countermeasures
 DevSecOps

• DevOps is a methodology for building software quickly by linking development and

operations
• It is a clipped compound of "software DEVelopment" and "information technology
OPerationS“ referring to a set of practices that accentuate the collaboration and
communication of both software developers and IT professionals that automate the
software delivery process
• DevSecOps involves considering application and infrastructure security from the start and
automating some security gates to keep the DevOps workflow from slowing down
• Choosing the right tools to continuously integrate security is critical
Identifying Security
Controls for Development
Authentication and session management

• The level of authentication needed by an

application should match the level of
sensitivity of that application
• Ensure that users are properly authenticated,
only conduct authorized actions, and that the
session is securely tracked
• Leverage IAM and SSO federated solutions for
best results and add MFA solutions if feasible
• Session tokens should demand periodic re-
authentication
Identifying Security
Controls for Development
Logging and visibility is critical

• Input validation weaknesses

• Authentication attempts and failures
• Access control failures
• Tampering attempts
• Use of invalid or expired session tokens
• Exceptions raised by the OS or programs
• Use of administrative or elevated privileges
• Transport Layer Security failures
• Cryptographic errors
Identifying Security
Controls for Development
• Security automation
• Offers consistency and greater frequency
• Continuous integration
• Consistently improving and updating your
software at a high standard
• Immutable systems
• The process of replacing instead of patching
• Infrastructure as code
• Infrastructure treated the same as code is
treated
• Forbidden coding techniques
Software DLC NX/XN Bit
• The NX bit stands for Never eXecute
• Technology is used in CPUs to
segregate areas of memory for use by
either storage of processor
instructions (code) or storage of data
• The NX bit is gradually being more
used in conventional processors for
security hardening
• The ARM architecture refers to this
feature, introduced in ARMv6, as XN
for eXecute Never
• This can effectively counter the buffer
overflow attack
ASLR and Code Quality
• Address space layout randomization
(ASLR) is a method used to help prevent
shellcode from being successful
• Also serves as a buffer overflow
countermeasure
• Randomly offsets the location of modules
and certain in-memory structures
• Data Execution Prevention (DEP) is closely
related
• prevents certain memory sectors (e.g.,
the stack) from being executed
• When used together, it becomes more
difficult to exploit vulnerabilities in
applications using shellcode or return-
oriented programming (ROP) techniques
 SQLi

• An attacker doesn’t necessarily need a SQLi attack as they can just

enter through open ports:
• MSFT SQL – TCP/1433
• Oracle – TCP/1521
SQL Injection • MySQL – TCP/3306
Attacks • Involves inserting a SQL query through input data from client to
server application
• Can allow for several exploits
• Read sensitive database data (SELECT FROM)
• Change database data (INSERT – UPDATE – DELETE)
• Execute administrative functions (e.g., shutdown DBMS)
• Get contents of files on database management system (DBMS)
• Run commands on operating system
 SQL “DO’s”

• Be familiar with common SQL injection attacks

• Know what the DB does
• Check input for validity
SQL Injection • Use parametrized queries (aka prepared statements)
Attacks • Store DB connection info outside the application
• Encrypt sensitive data whenever feasible
• Grant access to stored procedures and views – not
underlying DB tables
• Use WAF solutions that are dynamically updated
• NoSQL means “Not Only”
 SQL “DONT’s”

• Do not trust ANY input used to build SQL statements

• Do not use string concatenation to build SQL statements
• Do not execute untrusted parameters within stored
SQL Injection procedures
Attacks • Do not connect to the database as a highly privileged user
(such as “sa” or “root”)
• Do not embed the database login password in the
application or connection string
• Do not store DB config info in the web root
Cross-Site Scripting (XSS)
• Recently overtook buffer overflows as the most common attack
• Flaws in pages rendered by web servers and not the web server code itself (i.e.
Apache, IIS)
• Involves injection of malicious scripts or code into trusted or innocent web sites pages
• Attacker typically sends browser-side scripts to end user
• Can occur anytime a web program uses user input within the output it generates
without validating or encoding
• Malicious script can steal cookies, session tokens, or other sensitive data stored by
the browser and used with the site
Cross-Site Scripting (XSS)
DOM-based XSS
• Also called Local XSS or Type 0
• Does not involve vulnerable web servers
• Insecurely written HTML page on end user’s
system or local gadgets and widgets
• Allows the attacker to manipulate the DOM
through untrusted input
• They can render input that might lead to other
XSS vulnerabilities
• A gadget or a widget is simply a mini-application
built with web technologies like HTML,
JavaScript, and HTML
• Widgets – Apple, Nokia, Yahoo
• Gadgets – Microsoft and Google
Reflected XSS
• Also called Nonpersistent XSS or Type 1
• A classic input trust vulnerability where the
application is expecting some input (i.e. a query
string) and the attacker sends something
developer did not expect
• Example: attacker provides a JavaScript code
fragment as the querystring and the victim clicks
on the link
• Prevalent since it’s not feasible to turn off all
scripting in browsers
Stored XSS
• Also called Persistent XSS or Type 2
• A variant of type 1 where, rather than reflecting
the input, the web server persists the input
• The user is served up later to unsuspecting
victims
• Difference is an intermediate phase where the
untrusted input is stored in a file or a database
before unloading on the victim
• Often found in blogs and review/feedback web
applications
 Cross-site Request Forgery (CSRF/XSRF)

• Attack forces an end user to perform undesirable actions in a web application in which
they are authenticated
• An effective CSRF attack can force users to perform state-changing requests such as
• Transferring funds
• Changing their e-mail address
• Changing their password
• If the victim is an administrative account, the CSRF attack can compromise the entire
web application
Clickjacking
UI Redress Attack and Typosquatting
• Attacker uses several transparent layers to
trick users into clicking on a button or link
on one page, which then hijacks the user's
session and routes them to a different page
• Uses cleverly modified iFrames, style sheets,
and text boxes
• To counter, send the correct X-Frame-
Options HTTP response headers to tell the
browser not to allow framing from other
domains
• Also use defensive code in the UI to make
certain that the current frame is the most
top-level window
Cookie Problems
• Cookies were originally poorly designed
• Out of sync with browser same-origin
policy (SOP)
• SOP is important as the web browser allows
scripts stored in a first web page to access
data in a second web page, but only if both
web pages have the same origin

• Cookie manipulation attacks are rampant,

so countermeasures are critical:
• Update browsers
• Validate cookie integrity
• Deploy HTTP Strict Transport Security (HSTS)
HTTP Strict • HSTS is a web server directive that informs user agents and
Transport web browsers how to handle connections through a
response header sent at the very beginning and back to
Security the browser
(HSTS) • Sets the Strict-Transport-Security policy field parameter
• Forces those connections over HTTPS encryption,
disregarding any script's call to load any resource in that
domain over HTTP
• Deploy HTTP Strict Transport Security (HSTS) with
subdomain coverage
Additional • Buffer overflows occur when a program or process
Application attempts to write more data to a fixed length block of
memory, or buffer, than the buffer is allocated to hold
Security • Added data can overwrite values in memory addresses adjacent to
Concerns the destination buffer
• One of the most commonly patched vulnerabilities
• Memory leaks are a type of bug where a program fails to
release memory when it is no longer needed
• Memory leaks affect the performance of both the application and
the underlying operating system, and they will experience failures
Secure Coding
Principles
• Version control
• Track changes to code
• Document at GitHub or CSP for example
• Change management
• Direct, control, and support changes in
code efficiently
• Can be planned or unplanned
• Provisioning and deprovisioning
• Providing or removing software access
to employees, customers, partners, and
contractors
Secure Coding
Principles
• Proper error/exception handling
• Captured in logs, protect the logs, and
hide from users

• Proper input validation

• Verifying the input before entering it
into the system

• Normalization
• Ensuring there is no redundancy in data,
and that like items are stored together

• Stored procedures
• Precompiled groups of code, statements,
and commands that can be called later
Secure Coding
Principles
• Code signing and encryption
• Digitally signing code to prove author
and ensure integrity
• Ensure the confidentiality of the code in
transit, at rest, and in use

• Obfuscation/camouflage
• Deliberately use code that humans have
a hard time understanding

• Locate dead code

• Remove unnecessary, inoperative code
Secure Coding
Principles
• Server-side vs. client-side execution
and validation
• Both are acceptable
• Client-side is more efficient, but Server-
side is more secure

• Memory management
• Allocate memory/buffer when needed,
release it for re-use when no longer
needed

• Use of third-party libraries and SDKs

• May violate user's privacy, may damage
the quality of the application
Application Security
Frameworks
• Open Web Application Security Project
• OWASP is an online community that offers free
articles, methodologies, documentation, tools, and
technologies for web application security

• WS-Security (WSS)
• A SOAP extension to enforce web
confidentiality and integrity security

• Burp Suite
• Enterprise web application vulnerability
scanner
 Software Assurance
• The key objective of the Software Assurance Program is to shift the security paradigm
from patch management to software assurance
• Encourage developers to raise overall software quality and security from the start
• Emphasize the usage of tested standard libraries and modules
• Employ industry-accepted approaches that recognize that software security is
fundamentally a software engineering issue that must be addressed systematically
throughout the software development life cycle
 Security Requirements Traceability Matrix
(SRTM)
• A SRTM can provide a template for a software or system design document and
requirements definition
• It is a grid that provides visibility into the requirements for software or system security
• Traceability matrixes can be used for any type of project as they allow requirements and
tests to be easily traced
• The matrix is a way to ensure accountability for all processes and helps confirm that all
security tasks are completed
Security Requirements Traceability Matrix
(SRTM)
Enterprise Mobility BYOD
Management
Deployment Models - BYOD

• Bring Your Own Device

• Employees are permitted to use their
personal mobile devices to access
enterprise data and systems
• There are four basic options:
• Unlimited access for personal devices
• Access only to non-sensitive systems and data
• Access with IT control over personal devices,
apps, and stored data
• Access while preventing local storage of data
Enterprise Mobility CYOD
Management
Deployment Models - CYOD

• Choose Your Own Device is like BYOD in

that it lets employees work from
anywhere using a mobile device
• CYOD devices must be approved by the
organization, as opposed to BYOD
• Users often select from a list of approved
devices, which are usually smartphones
• These networks offer more stability,
security, and simplified IT for most
businesses
Enterprise Mobility COPE
Management
Deployment Models - COPE

• Corporate-owned Personally-enabled
(COPE)
• Company gives employees mobile
devices
• Users can handle as if they were their
own
• Prevents the need for two smartphones
• Programs should use containerization
tools
 • Organizations must securely configure and implement each
layer of the technology stack, including mobile hardware,
Enterprise firmware, O/S, management agent, and the apps used for
business
Mobility
• Solution should reduce risk, so employees are able to access
Management the necessary data from nearly any location, over any
(EMM) network, using a wide variety of mobile devices
• Enterprise mobility management is the combination of
mobile device management (MDM) and mobile application
management (MAM)
 Mobile Device Management (MDM)
• Technology to enable the management and control
of mobile devices used to access business
resources
• Enrolling devices for management
• Provisioning settings like digital certificates and profiles
• Monitoring, measuring, and reporting device compliance
• Removing corporate data from devices (data leak
prevention)

• Some activities are network access control,

preadmission control, remote lock and wipe
• Other features that can sometimes be attributed to
MDM platform are remote virtual private network
(VPN) capabilities
 Mobile Application Management (MAM)
• Involves publishing mobile apps to users
• Continual monitoring, configuration, and
updating of apps
• Mobile managers will report on app
inventory and usage
• Secure and removing corporate data
within mobile apps
• Also involves mobile content management
 Mobility Security and Privacy Concerns

• Geolocation
• Know your policy for enabling geolocation as this is a vulnerability for certain sectors
• Geotagging
• There is a risk of social surveillance by GPS with geotagging
• Geofencing
• Geofencing can be used to put restrictions on where a
mobile device can be actively used based on GPS
• It could be based on RFID tagging
 Mobility Security and Privacy Concerns

• Data storage and remnants

• Non-removable storage
• Removable storage
• Cloud storage
• Transfer/backup data to
uncontrolled storage
 • Jailbreaking and rooting are very different, even though
they both involve privilege escalation
• Jailbreaking an iPhone basically allows the installation of
third-party apps not approved by Apple’s strict controls
Jailbreaking • You cannot modify the OS or system files like an
administrator and you’re still bound by the iOS framework
• A jailbroken iPhone can be reverted back to a standard
'jailed' device by restoring the device in Recovery Mode
• Apple has responded with patching exploits and upgrading
hardware to iOS
 • Rooting grants full access to a device on a level much
higher than jailbreaking, giving access to the Android
system and beyond
• Every line of code in the Linux-based device becomes
Rooting editable, with options only restricted by coding skills
• Since Android is open source, you can go into recovery
mode and download a modified or even entirely new
version of the OS if you want
• You can alter any and all hardware, software, or aesthetic
settings on the device
 • Sideloading basically refers to the moving of media files to
a mobile device using USB, Bluetooth, or Wi-Fi
• It can also involce writing to a memory card to insert into a
mobile device
Sideloading • With Android apps, sideloading usually installs an app
package in APK format onto a device, with packages
typically downloaded from sites other than Google Play
• Sideloading of apps is only likely if the user has allowed
"Unknown Sources" in their security settings
Tethering and Other
Challenges
• Tethering
• Using device as a wireless
• Unauthorized domain bridging
• Install regular patches and updates on
wireless devices to prevent bridging and
tethering from others

• Spectrum management
• New bandwidths opening up that could be
used in an unauthorized manner
Tethering and Other
Challenges
• USB On The Go (USB OTG)
• Allows mobile devices to directly connect to
one another
• As a host, additional hardware (storage,
keyboards, cameras, and more) can work
together with your USB OTG handset

• Device loss or theft

• Device tracking
• Remote lock
• Remote wipe
Tokenization and
Mobile Payment
Concerns
• Tokenization
• Used for mobile payments and multifactor
authentication (MFA)

• Mobile payment
• Near-field communication (NFC) enabled
• Mobile wallet
• Peripheral-enabled payments
(credit card reader)
Containerization and
Sandboxing
• Provides protection, isolation, and
integrity functionality to get better levels
of overall data isolation
• Containerization is technically a (MAM)
technique that limits the environments in
which certain code can run
• Users can continue to chat, text, and
tweet without affecting business
functions since sensitive apps and data
remain protected within sandboxed
containers with separate controls and
higher security levels
 Application Wrapping

• Involves adding an additional

management layer
• Allows MAM administrator to set
specific policy elements that can be
applied to an application or group
of applications
• Whether or not user authentication is
needed for a certain app
• Whether or not app data can be stored
on the device at all
• Whether or not specific APIs (e.g., file
sharing) will be permitted
 Secure Encrypted
Enclaves
• Secure Enclave Processor (SEP) is a
security circuit designed to perform
secure services for the rest of the
SoC
• Introduced in first 64-bit phone for
Touch ID
• M7 motion coprocessor
• Secure sensitive data storage using
fingerprint data, cryptographic
keys, etc.
 Secure Encrypted
Enclaves
• Prevents main processor from
gaining direct access to sensitive
data
• SEPOS includes its own kernel,
drivers, services, and applications
• Has its own set of peripherals
accessible by memory-mapped
dedicated I/O lines
• Uses inline AES to encrypt external
RAM
 • OEMs with different features
• Lack of carrier standardization
OEM and
• Geographic regional differences
Carrier • Legal jurisdictions
Fragmentation
 • eFuse was originally conceived by IBM as a simple way to
change the function and performance of a chip in real time
• The redesigned chip can reroute chip logic, similar to the
eFuse way highway traffic patterns can be changed by opening
and closing new lanes
• Another use is to prevent the downgrading of firmware of
a device like a mobile phone or gaming system
• Reverse engineering can lead to security vulnerabilities
Emerging Mobile
Authentication
• PIN code
• Swipe pattern
• Gesture technology
• Two-factor and multifactor
authentication (2FA and MFA)
• Facial recognition
• Fingerprint
• Iris scan
Embedded Device
Vulnerabilities
• The explosion of Internet of Things (IoT)
and Internet of Everything (IoE) presents
a challenge for embedding computing
vulnerability discovery
• Systems are powered by specialized chips
and some version of Linux or older
Microsoft Windows
• No one entity has any incentive,
expertise, or even ability to patch the
software once it's shipped
Embedded Device
Vulnerabilities
• Complete embedded source code is
often not available
• Many of the device drivers and other
components are simply binary stes with
no source code at all
• Even if a patch is available, it is rarely
applied in a consistent manner
• Hundreds of millions of devices are
sitting on the Internet, unpatched and
unsecured, for the last ten years or so
Common Threats to
Embedded Devices
• Code injection (SQLi, C)
• Successful attacks can give the attacker
complete control over the entire machine to
steal data, force malfunction, infect with
worm (botnet), or render inoperable

• Unsecure direct object references

• Improper error and exception handling
Common Threats to
Embedded Devices
• Poor identity and access management
(IAM) leading to privilege escalation
• Improper input validation
• Improper storage of sensitive data
• No fuzzing/fault-injection testing
Mitigating Threats to
Embedded Devices
• There are two golden rules for preventing
code-injection vulnerabilities
• Don’t interpret data as code if you can avoid
it
• If you can’t avoid it, make sure you validate
that the data is well formed before using it

• Conduct fuzzing and static analysis

• Scan embedded systems with Nessus or
other vulnerability scanners
• Use mature and established versions
Mitigating Threats to
Embedded Devices
• Test in cloud before deployment
• Change and configuration management
• Patch management
• Digitally signed code
• Trusted OS and firmware
• Hire skilled systems/security
practitioners