Architecture and Design Flashcards
The only constant is change
- Operating systems, patches, application updates, network modifications, new application instances, etc.
Identify and document hardware and software settings
- Manage the security when changes occur
Rebuild those systems if a disaster occurs
- Documentation and processes will be critical
Configuration Management
Network diagrams - Document the physical wire and device
Physical data center layout - Can include physical rack locations
Device diagrams - Individual cabling
Diagrams
The security of an application environment should be well defined
- All application instances must follow this
- Firewall settings, patch levels, OS file versions
- May require constant updates
Integrity measurements check for the secure baseline
- These should be performed often
- Check against well-documented baselines
- Failure requires an immediate correction
Baseline configuration
Create a standard
- Needs to be easily understood by everyone
Devices
- Asset tag names and numbers
- Computer names - location or region
- Serial numbers
Networks - Port labeling
Domain configurations
- User account names
- Standard email addresses
Standard naming conventions
An IP address plan or model
- Consistent addressing for network devices
- Helps avoid duplicate UP addressing
Locations
- Number of subnets, hosts per subnet
IP ranges
- Different sites have a different subnet
- 10.1.x.x/24, 10.2.x.x/24, 10.3.x.x/24
Reserved addresses
- Users, printers, routers/default gateways
IP schema
Data that resides in a country is subject to the laws of that country
- Legal monitoring, court orders, etc
Laws may prohibit where data is stored
- GDPR (General Data Protection Regulation)
- Data collected on EU citizens must be stored in the EU
- A complex mesh of technology and legalities
Where is your data stored?
- Your compliance laws may prohibit moving data out of the country
Data sovereignty
Data obfuscation
- Hide some of the original data
Protects PII
- and other sensitive data
May only be hidden from view
- The data may still be intact in storage
- Control the view based on permissions
Many different techniques
- Substituting, shuffling, encrypting, masking out, etc.
Data masking
Encode information into unreadable data
- Original information is plaintext, encrypted form is ciphertext
This is a two-way street
- Convert between one and the other
- If you have the proper key
Confusion
- The encrypted data is drastically different than the plaintext
Diffusion
- Change one character of the input, and many characters change of the output
Data encryption
The data is on a storage device
- Hard drive, SSD, flash drive, etc
Encrypt the data
- Whole disk encryption
- Database encryption
- File or folder-level encryption
Apply permissions
- Access control lists
- Only authorized users can access the data
Data at-rest
Data transmitted over the network
- Also called data in-motion
Not much protection as it travels
- Many different switches, routers, devices
Network, based protection
- Firewall, IPS
Provide transport encryption
- TLS (Transport Layer Security)
- IPsec (Internet Protocol Security)
Data in-transit
Data is actively processing in memory
- System RAM, CPU registers and cache
The data is almost always decrypted
- Otherwise, you can’t do anything with it
The attackers can pick the decrypted information
- A very attractive option
Data in-use
Replace sensitive data with a non-sensitive placeholder
Common with credit card processing
- Use a temporary token during payment
- An attacker capturing the card numbers can’t use them later
This isn’t encryption or hashing
- The original data and token aren’t mathematically related
- No encryption overhead
Tokenization
Control how data is used
- Microsoft Office documents, email messages, PDFs
Restrict data access to unauthorized persons
- Prevent copy and paste
- Control screenshots
- Manage printing
- Restrict editing
Each user has their own set of rights
- Attackers have limited options
Information Rights Management (IRM)
Where’s your data?
- Social Security numbers, credit card numbers, medical records
Stop the data before the attackers get it
- Data “leakage”
So many sources, so many destinations
- Often requires multiple solutions in different places
Data Loss Prevention (DLP)
On your computer
- Data in use
- Endpoint DLP
On your network
- Data in motion
On your server
- Data at rest
Data Loss Prevention (DLP) systems
Legal implications
- Business regulations vary between states
- For a recovery site outside of the country, personnel must have a passport and be able to clear immigration
- Refer to your legal team
Offsite backup
- Organization-owned site or 3rd-party secure facility
Offsite recovery
- Hosted in a different location, outside the scope of the disaster
Travel considerations for support staff and employees
Geographical considerations
Incident response and recovery has become commonplace
- Attacks are frequent and complex
Incident response plan should be established
- Documentation is critical
- Identify the attack
- Contain the attack
Limit the impact of an attacker
- Limit data exfiltration
- Limit access to sensitive data
Response and recovery controls
Commonly used to examine outgoing SSL/TLS
- Secure Sockets Layer/Transport Layer Security
SSL/TLS relies on trust
- Without trust, none of this works
Your browser contains a list of trusted CAs
Your browser doesn’t trust a website unless a CA has signed the web server’s encryption certificate
- The website pays some money to the CA for this
The CA has ostensible performed some checks
- Validated against the DNS record, phone call, etc.
Your browser checks the web server’s certificate
- If it’s signed by a trusted CA, the encryption works seamlessly
SSL/TLS Inspection
Represent data as a short string of text
- A message digest
One-way trip
- Impossible to recover the original message from the digest
- Used to store passwords/confidentiality
Verify a downloaded document is the same as the original
- Integrity
Can be a digital signature
- Authentication, non-repudiation, and integrity
Will not have a collision (hopefully)
- Different messages will not have the same hash
Hashing
Control software or hardware programmatically
Secure and harden the login page
On-path attack
- Intercept and modify API messages, replay API commands
API injection
- Inject data into an API message
DDoS
- One bad API call can bring down a system
API considerations
Recovery site is prepped
- Data is synchronized
A disaster is called
- Business processes failover to the alternate processing site
Problem is addressed
- This can take hours, weeks, or longer
Revert back to the primary location
- This process must be documented for both directions
Site resiliency
A exact replica
- Duplicate everything
Stocked with hardware
- Constantly updated
- You buy two of everything
Applications and software are constantly updated
- Automated replication
Flip a switch and everything moves
- This may be quite a few switches
Hot site
No hardware
- Empty building
No data
- Bring it with you
No people
- Bus in your team
Cold site
Somewhere between a hot and cold site
- Just enough to get going
Big room with rack space
- You bring the hardware
Hardware is ready and waiting
- You bring the software and data
Warm site
Attract the bad guys
- And trap them there
The “attacker” is probably a machine
- Makes for interesting recon
Create a virtual world to explore
Constant battle to discern the real from the fake
Honeypots
More than one honeypot on a network
More than one source of information
Honeynets
Bait for the honeynet
An alert is sent if the file is accessed
A virtual bear trap
Honeyfiles
Machine learning
- Interpret big data to identify the invisible
Train the machine with actual data
- Learn how malware looks and acts
- Stop malware based on actions instead of signatures
Send the machine learning model fake telemetry
- Make malicious malware look benign
Fake telemetry
Sometimes called Hardware as a Service (HaaS)
- Outsource your equipment
You’re still responsible for the management
- And for the security
Your data is out there, but more within your control
Web server providers
Infrastructure as a service (IaaS)
No servers, no software, no maintenance team, no HVAC
- Someone else handles the platform, you handle the development
You don’t have direct control of the data, people, or infrastructure
- Trained security professionals are watching your stuff
- Choose carefully
Put the building blocks together
- Develop your app from what’s available on the platform
- SalesForce.com
Platform as a service (PaaS)
On-demand software
- No local installation
- Why manage your own email distribution or payroll?
Central management of data and applications
- Your data is out there
A complete application offering
- No development work required
- Google Mail
Software as a service (SaaS)
A broad description of all cloud models
- Use any combination of the cloud
Services delivered over the internet
- Not locally hosted or managed
Flexible consumption model
- No large upfront costs or ongoing licensing
IT becomes more of an operational model
- And less of a cost-center model
- Any IT function can be changed into a service
Anything as a service (XaaS)
Provide cloud services
- SaaS, PaaS, IaaS, etc
Charge a flat fee or based on use
- More data, more cost
You still manage your processes
- Internal staff
- Development team
- Operational support
Cloud service providers
UPDATE
Managed service providers (MSP)
Firewall management
Patch management, security audits
Emergency resonse
Managed Security Service Provider (MSSP)
Your applications are on local hardware
Your servers are in your data center in your building
On-premise cloud model
Your servers are not in your building
They may not be even running on your hardware
Usually a specialized computing environment
Off-premise cloud model
Available to everyone over the internet
Public cloud deployment
Several organizations share the same resources
Community cloud deployment
Your own virtualized local data center
Private cloud deployment
A mix of public and private
Hybrid cloud model
Over 30 billion IoT devices on the internet
- Devices with very specific functions
- A huge amount of data
Process application data on an edge server
- Close to the user
Often process data on the device itself
- No latency, no network requirement
- Increased speed and performance
- Process where the data is, instead of processing in the cloud
Edge computing
A cloud that’s close to your data
- (Cloud + IoT - Fog Computing)
A distributed cloud architecture - extends the cloud
Distribute the data and processing
- Immediate data stays local - No latency
- Local decisions made from local data
- No bandwidth requirements
- Private data never leaves - Minimizes security concerns
- Long-term analysis can occur in the cloud - Internet only when required
Fog computing
Basic application usage
- Applications actually run on a remove server
- Virtual Desktop Infrastructure (VDI)
- Desktop as a Service (DaaS)
- Local device is a keyboard, mouse, and screen
Minimal operating system on the client
- No huge memory or CPU needs
Network connectivity
- Big network requirement
- Everything happens across the wire
Thin client
Run many different operating systems on the same hardware
Each application instance has its own operating system
- Adds overhead and complexity
- Virtualization is relatively expensive
Virtualization
Contains everything you need to run an application
- Code and dependencies
- A standardized unit of software
An isolated process in a sandbox
- Self-contained
- Apps can’t interact with each other
Container image
- A standard for portability
- Lightweight, uses the host kernal
- Secure separations between applications
Application containerization
Monolithic applications
- One big application that does everything
Application contains all decision making processes
- User interface
- Business logic
- Data input and output
Code challenges
- Large codebase
- Change control challenges
APIs
- API is the glue for the microservices
- Work together to act as the application
Scalable
- Scale just the microservices you need
Resilient
- Outages are contained
Security and compliance
- Containment is built-in
Microservices/APIs
Function as a Service
- Applications are separated into individual, autonomous functions
- Remove the operating system from the equation
Developer still creates the server-side logic
- runs in a stateless compute container
May be event triggered and ephemeral
- May only run for one event
Managed by a third-party
- All OS security concerns are at the third-party
Serverless architecture
Virtual Private Cloud
- A pool of resources created in the public cloud
Common to create many VPCs
- Many different application clouds
Connect VPCs with this
- And users to VPCs
- A “cloud router”
Now make it secure
- VPCs are commonly on different IP subnets
- Connecting through the cloud is often through a VPN
Transit gateway
Assigning permissions to cloud resources
- Not the easiest task
- Everything is in constant motion
Specify which resources can be provisioned (Azure)
- Create a service in a specific region, deny all others
Specify the resource and what actions are permitted (Amazon)
- Allow access to an API gateway from an IP address range
Explicitly list the users who can access the resource (Amazon)
- Userlist is associated with the resource
Resource policies
Many different service providers
- The natural result of multi-sourcing
Every provider works differently
- Different tools and processes
Provides a single business-facing IT organization
An evolving set of processes and procedures
Service Integration and Management (SIAM)
Describe as infrastructure
- Define servers, network, and applications as code
Modify the infrastructure and create versions
- The same way you version application code
Use the description (code) to build other application instances
- Build it the same way every time based on the code
An important concept for cloud computing
- Build a perfect version every time
Infrastructure as code
Networking devices have two functional planes of operation
- Control plane, data plane
Directly programmable
- Configuration is different than forwarding
Agile - Changes can be made dynamically
Centrally managed - Global view, single pane of glass
Programmatically configured
- No human intervention
Open standards/vendor neutral
- A standard interface to the network
Software Defined Networking (SDN)
You must see the traffic to secure the data
- React and respond
Dynamic deployments include security and network visibility devices
- Next-generation firewalls, web application firewalls
- SIEM
Data is encapsulated and encrypted
- VXLAN and SSL/TLS
New technologies change what you can see
- Infrastructure as code, microservices
Security devices monitor application traffic
- Provides visibility to traffic flows
Visibility expands as the application instances expand
- Real-time metrics across all traffic flows
Application flows can be controlled via API
- Identify and react to threats
Software Defined Visibility (SDV)
Click a button
- You’ve built a server
- Or multiple servers, networks, and firewalls
It becomes almost too easy to build instances
- this can get out of hand very quickly
The virtual machines are sprawled everywhere
- You aren’t sure which VMs are related to which applications
- It becomes extremely difficult to deprovision
Formal process and detailed documentation
- You should have information on every virtual object
VM sprawl avoidance
The virtual machine is self-contained
- There’s no way out - Or is there?
Virtual machine escape
- Break out of the VM and interact with the host operating system or hardware
Once you escape the VM, you have great control
- Control the host and control other guest VMs
This would be a huge exploit
- Full control of the virtual world
VM escape protection
Secure environment
Writing code
Developers test in their sandboxes
Development environment
Still in the development stage
All of the pieces are put together
Functional tests
Does it work?
Test environment
Verifies features are working as expected
Verifies new functionality
Verifies old errors don’t reappear
Quality Assurance (QA)
Almost ready to roll it out
Works and feels exactly like the production environment
Working with a copy of production data
Runs performance tests
Test usability and features
Staging
Application is live
Rolled out to the user community
Challenging step
- Impacts the users
Logistical challenges
- New servers
- New software
- Restart or interrupt of service
Production
Deploy an application
- Web server, database server, middle server, user workstation configuration, certificate updates, etc
Application software security
- Operating system, application
Network security
- Secure VLAN, internal access, external access
Software deployed to workstations
- Check executes for malicious code, verify security posture of the workstation
Provisioning
The ability to increase the workload in a given infrastructure
Build an application instance that can handle
Scalability
Increase or decrease available resources as the workload changes
Deploy multiple application instances to handle
Elasticity
Dismantling and removing an application instance
- All good things
Security deprovisioning is important
- Don’t leave open holes, don’t close important ones
Firewall policies must be reverted
- If the application is gone, so is the access
What happens to the data?
- Don’t leave information out there
Deprovisioning
A balance between time and quality
- Programming with security in mind is often secondary
Testing, testing, testing
- The Quality Assurrance (QA) process
Vulnerabilities will eventually be found
- And exploited
Secure coding concepts
SQL databases
- Client sends detailed requests for data
Client requests can be complex
- And sometimes modified by the user
- This would not be good
These limit the client interactions
- That’s it. No modifications to the query are possible.
Stored Procedures
Make something normally understandable very difficult to understand
Take perfectly readable code and turn it into nonsense
- The developer keeps the readable code and gives you the chicken scratch
- Both sets of code perform exactly the same way
Helps prevent the search for security holes
- Makes it more difficult to figure out what’s happening- But not impossible
Obfuscation
Use old code to build new applications
- Copy and paste
If this has security vulnerabilities, reusing the code spreads it to other applications
- Making this much more difficult for everyone
Code reuse
Calculations are made, code is executed, results are tallied
The results aren’t used anywhere else in the application
All code is an opportunity for a security problem
- Make sure your code is as alive as possible
Dead code
All checks occur on the server
Helps protect against malicious users
Attackers may not be even using your interface
Server-side validation
The end-user’s app makes the validation decisions
Can filter legitimate input from genuine users
May provide additional speed to the user
Client-side validation
As a developer, you must be mindful of how memory is used
- Many opportunities to build vulnerable code
Never trust data input
- Malicious users can attempt to circumvent your code
Buffer overflows are a huge security risk
- Make sure your data matches your buffer sizes
Some built-in functions are insecure
- Use best practices when designing your code
Memory management
Your programming language does everything - Almost
Third-party libraries and software development kits
- Extend the functionality of a programming language
Security risk
- Application code written by someone else
- Might be secure. Might not be secure.
- Extensive testing is required
Balancing act - Application features vs. unknown code base
Third-party libraries and SDKs
So much sensitive data
- Credit card numbers, social security numbers, medical information, address details, email information
How is the application handling the data?
- No encryption when stored
- No encryption across the network
- Displaying information on the screen
All input and output processes are important
- Check them all for data exposure
Data exposure
Create a file, make a change, make another change, and another change
- Track those changes, revert back to previous version
Commonly used in software development
- But also in operating systems, wiki software, and cloud-based file storage
Useful for security
- Compare versions over time
- Identify modifications to important files
- A security challenge
- Historical information can be a security risk
Version control
Alternative compiler paths would result in different binary each time
- Each compiled application would be a little bit different
- But functionality the same
An attack against different binaries would only be successful on a fraction of the users
- An attacker wouldn’t know what exploit to use
- Make the game much harder to win
Software diversity
Plan for change
- Implement automatically
Automated courses of action
- Many problems can be predicted
- Have a set of automated responses
Continuous monitoring
- Check for a particular event, and then react
Configuration validation
- Cloud-based technologies allow for constant change
- Automatically validate a configuration before going live
- Perform ongoing automated checks
Automation and scripting
Code is constantly written
- And merged into the central repository many times a day
So many chances for security problems
- Security should be a concern from the beginning
Basic set of security checks during development
- Documented security baselines as the bare minimum
Large-scale security analysis during the testing phase
- Significant problems will have already been covered
Continuous Integration (CI)
Keep all of an organization’s usernames and passwords in a single database
- Also contains computers, printers, and other devices
Large distributed database
- Constantly replicated
All authentication requests reference this directory
- Each user only needs one set of credentials
- One username and password for all services
Access via Kerberos or LDAP
Directory services
Provide network access to others
- Not just employees - Partners, suppliers, customers, etc
- Provides SSO and more
Third-parties can establish network this
- Authenticate and authorize between the two organizations
- Login with your Facebook credentials
The third-parties must establish a trust relationship
- And the degree of the trust
Federation
Prove the hardware is really yours
- A system you can trust
Easy when it’s just your computer
- More difficult when there are 1,000
Attestation
Device provides an operational report to a verification server
Encrypted and digitally signed with the TPM
An IMEI or other unique hardware component can be included in the report
Remote attestation
Text messaging
- Includes more than text these days
Login factor can be sent via SMS to a predefined phone number
- Provide username and password
- Phone receives an SMS
- Input the SMS code into a login form
Security issues exist
- Phone number can be reassigned to a different phone
- SMS messages can be intercepted
Short message service (SMS)
Similar process to a SMS notification
- Authentication factor is pushed to a specialized app
- Usually on a mobile device
Security challenges
- Applications can be vulnerable
- Some push apps send in the clear
Still more secure than SMS
- Multiple factors are better than one factor
Push notification
Pseudo-random token generators
- A useful authentication factor
Carry around a physical hardware token generator
Use software-based token generator on your phone
- Powerful and convenient
Authentication apps
Use a secret key and the time of day
- No incremental counter
Secret key is configured ahead of time
- Timestamps are synchronized via NTP
Timestamp usually increments every 30 seconds
- Put it your username, password, and TOTP code
One of the more common OTP methods
- Used in Google, Facebook, Microsoft, etc
Time-based One-Time Password algorithm (TOTP)
One time password
- Use them once, and never again
- Once a session, once each authentication attempt
Hashed One-Time password (HOTP)
A voice call provides the toke
- The computer is talking to you
- “Your code is 1-6-2-5-1-7”
Similar disadvantages to SMS
- Phone call can be intercepted or forwarded
- Phone number can be added to another phone
Phone call
Authentication factors that don’t change
- You just have to remember
Personal Identification Number (PIN)
- Your secret numbers
Can also be alphanumeric
- A password or passphrase
Static codes
Integrated circuit card - Contact or contactless
Common on credit cards - Also used for access control
Must have physical card to provide digital access
- A digital certificate
Multiple factors
- Use the card with a PIN or fingerprint
Smart cards
Fingerprint scanner
- Phones, laptops, door access
Retinal scanner
- Unique capillary structure in the back of the eye
Iris scanner
- Texture, color
Voice recognition
- Talk for access
Facial recognition
- Shape of the face and features
Gait analysis
- Identify a person based on how they walk
- Many unique measurements
Veins
- Vascular scanners
- Match the blood vessels visible from the surface of the skin
Biometric factors
Likelihood that an unauthorized user will be accepted
- Not sensitive enough
False acceptance rate (FAR)
Likelihood than an authorized user will be rejected
- Too sensitive
False rejection rate (FRR)
Defines the overall accuracy of a biometric system
- The rate at which FAR and FRR are equal
- Adjust sensitivity to equalize both values
Crossover error rate (CER)
This is who you claim to be
- Usually your username
Identification (AAA framework)
Prove you are who you say you are
- Password and other factors
Authentication (AAA framework)
Based on your identity and authentication, what access do you have?
Authorization (AAA framework)
Resources used: Login time, data sent and received, logout time
Accounting (AAA framework)
Third-party can manage the platform
- Centralized platform
- Automation options with API integrations
- May include additional options (for a cost)
Cloud-based security authentication
