2.1 - Enterprise Environment Security Concepts Flashcards
Configuration management
- Challenges: Constantly changing
- Ex: Updates to OS, patches, application updates, network modifications, new application instances, etc.
Documentation
- Must be modified and updated as configuration management
- Documentation should allow you to rebuild your entire application instance from the beginning with just your documentation
Network diagram
- An example of a configuration management document
- Documents the physical wire and device
- Can include physical data center layout (physical rack locations)
- Can show what devices are connected to each other
- May also want to include info about patch cable/ panel locations (tracking path a wire takes from beginning to end)
Data Center
- Racks can be connected under the floor, you can document what’s on the inside of each rack
Application Baseline
- Want to include firewall settings, patch levels, OS file versions, may require constant updates
- This is your baseline configuration (this needs to be documented)
- It can be verified through the documentation with an Integrity Measurement Check
Integrity Measurement Check
- Verify that all details in documentation are running in applications (checks to see if your documentation aligns with application)
- If you find deviations, you need to understand how to correct them
- Should be performed often
Standard Naming Conventions
- Need to be understood by everyone
- Ex: Asset tag, name of computer, location
- clear labels
- Port Labeling
- Standard user name/ emails in servers
- Can label rack rows
IP Schema
- Can include IP standardization
- Ex: standardize the number of subnets associated with an IP address range
- helps avoid duplicate IP addressing
- Could have reserved addresses for IP gateways, printers, routers, other devices
Protecting data difficulties
- Could be in many locations
- Ex: Storage drive, on the network, in a CPU
- Combine technologies with data for protection (Ex: encryption / security policies)
- Use permissions to control access
Data Sovereignty
- Determines how data is protected in different areas
- Understand the laws regarding data depending on where the data geographically resides
GDPR
- General Data Protection Regulation
- EU
- Data collected on EU citizens must be stored in the EU
- extensive and complex so you need to understand if you’re planning to collect it
- many similarities in other countries
Masking
- A way to protect data
- Obfuscate the original data to make it harder to read
- Ex: putting asterisks over credit card number on a receipt (but the full data could be stored on a server, but the physical copy would be masked)
- Ex: Can substitute numbers or use completely different information
- Essentially controlling view based on permissions
- Can be used to protect to PII and sensitive data
Encryption
- A way to protect data
- original text vs ciphertext (before and after encryption)
- Allows you to go back and forth if you have the proper key and proper processing
- Encryption uses confusing since the encrypted text is drastically different than the plain text
Diffusion
- Related to encryption / data protection
- If you change one character in plain text, the resulting encryption will be dramatically different
- difficult to tell it’s a similar plain text
Data at-rest
- Data on a storage device
- EX: hard drive, SSD, flash drive, etc.
Securing large amounts of data at - rest
- Ex: Whole disk encryption, database encryption, file or folder level encryption
- Can assign permissions by users/ groups of users to certain files etc.
Data in-transit
- AKA data in motion
- Ex: data moving between switches, routers, all different devices
- often all / deny passage through network based protect (Firewall / IPS)
Network-based protections
- Ex: Firewall, IPS (intrusion preventions system)
- can encrypt
- TLS (Transport Layer Security), which is the newer SSL and IPsec (Internet Protocol Security) will encrypt data in transit
Data in-use
- Data that is actively processing in memory
- Ex: System RAM, CPU registers, cache
- Almost always decrypted (b/c easier to perform calculations and actually use it)
- B/c it’s in memory and decrypted its a very tempting place for hackers to focus their efforts
Tokenization
- A way to protect data
- Take sensitive data and replace it with a non-sensitive placeholder
- Ex: replacing a SSN with random numbers
- Ex: common with credit card numbers and transactions
- Not the same thing as hashing or encryption (the original data and token aren’t mathematically related)
- No encryption overhead (computational overhead)
Tokenization process
- User registers credit card on their phone ->
- Sent to a Remote Token Service Server ->
- Server sends back to phone a token ->
- Phone is used at store to buy something using NFC (near field communication) ->
- Information goes to the merchant’s payment processing server - >
- Goes to Remote token service Server ->
- This will confirm to the merchant’s server that the token is valid and it will be approved
NFC
- Near field communication
- Ex: when you use your phone / watch to pay for something at a store
- Often an example of the tokenization process
IRM
- Information Rights Management
- Goal prevent someone from doing something with a document, if someone got a hold of someone’s document they could only manipulate within the scope of the user’s rights and privileges
- Ex: Office documents or PDFs that won’t let you change something
- Ex: prevent copying / pasting / preventing screen shots/ restrict editing
DLP
- Data Loss Prevention
- Where is your data?
- Stop the data before the attackers get it, prevent “leakage”
- Need to look at multiple solutions in multiple places to protect our data
End point DLP
- Good idea to have DLPs for these areas: to protect data
- On your local: Examines everything that is transferred into and out of our device (on local computer). Data in use.
- On the network: Data in Motion.
- On your server (data at rest)
USB Blocking
- Type of DLP
- Important to protect what can / can’t be allowed with USB
Cloud based DLP
- Outside of our network
- Located b/n users and the internet
- Watches every byte of network traffic
- no hardware, no software
- Can also block predefined data strings (data flow)
- Can manage access to URLs, prevent fie transfers to cloud storage
- can block virus / malware
DLP and email
- Looks at inbound / outbound
- blocks anything that is sensitive
- Can block keywords, identify imposters, quarantine and then be examined by security personnel
- Can block outbound things like wire transfers, W2 transmissions, employee information
Geographical considerations
- Legal implications (ex: state to state, internationally)
- All personnel must have a passport if international and be able to clear immigration
- Use your legal team as support (internal or third party), should always be involved with how your data / systems are managed
Offsite back
- on site or offsite
- What type of control do you have if off site
- More importantly, what kind of access does a 3rd party have?
Offsite Recovery
- Do you have a way to get ppl to that location
Response and recovery contrls
- Incident response / recovery has become commonplace
- b/c attacks are frequent and complex
- An incident response plan should be established
Incident Response plan
- In the event of an attack do you have a plan?
- Should be extensively documented (time consuming but very important)
- Identify the attack
- Contain the attack
- Limit the scope of attack
- Cant prevent it at this point, but can limit how ppl get data out of our system (limit data exfiltration)
- Limit access to sensitive data
SSL / TLS inspection
- Secure Socket Layer / Transport Layer Security
- ppl shouldn’t be using SSL
- Challenge: there may be information in the encrypted data that may be malicious
- There are ways to perform SSL / TLS inspection (viewing data inside the encrypted data for inspection)
- Not done easily and must be specially configured, but a useful tool
- All based on trust (your browser trusts the device it’s connecting to on the other end in order to perform end to end encryption)
- For the SSL / TSL inspection, put yourself in the middle of the conversation but continue having trust on client / server side
CA
- Certificate Authority
- Embedded inside of browswer inside of device
- Ex: a given browswer can contain around 170 trusted CA Certs
- Every site on the internet has to be an interaction with a CA
- As a user you check the signature and ensure it matches the correct certificate
- We’re also trusting that the certificate authority has done their job to ensure that they’re doing the verifications before signing the web server certificate
- Your browswer then checks the web server’s certificate, if it’s signed by a trusted CA, then the encryption works
SSL / TLS Proxy
- How do we get in the middle of the conversation?
- Need a device in the middle of the conversation.
- Ex: Firewall or SSL decrption
- We will add our own internal CA certificate (only for internal use with company, not external)
- Add this to all company devices and all browsers
- This ensures that all company browsers trust the internal CA
- Can then begin the process of securely communicating b/n a user and a server
- User -> (sends message to server)
- This hits the Firewall the company established, it receives the message and send a proxy version of the same message to the webserver
- webserver then responds with info about Public CA
- internal firewall will check out the info on this CA and verify
- then it will create a new certificate for use on the network (decrypting it and then sending to user)
- This allows company to sit in the middle of the conversation, analyzed, verified, ensure nothing is malicious
Hashing
- Represent data as a short string of text
- “message digest”
- One - way trip (unlike encryption which is two ways)
- In hashing, once you create the hash, there is no way to undo it
- This is why it’s used for passwords, it’s confidential
- Can verify hashes when downloading document to see if it’s the same hash that was originally created for the document when you download it
- Can be a digital signature (authentication, non-repudiation, integrit)
- One important feature (and reason why older hashes are often retired) - run into issues w/ collision
- Uses: Encryption, digital signatures, cryptography processes
- If one character is different, the hash should still look very different, if it doesn’t know you’ve got a vulnerability
Collision
- In hashing, when two different, original messages end up with the same hash (should never happen)
- One reason why hashes are retired
- This indicates a cryptographic vulnerability in the hashing algorithm
- EX: SHA256 hash (a good algorithm) - 256 bits, or 64 characters
API Considerations
- Application Programming Interfaces
- Control hardware / software programmatically
- Have to put in protections that is being sent / received on the API calls
- Ex: users can interact on the login page and a user the mobile app might be logging in using the API (have to make sure you’re managing security for interactive users AND APIs)
On-path attack
- A way attackers exploit APIs
- Attacker sits in the middle of a conversation and can modify / replay some of the traffic in the API call
- Attacker can watch the conversation to get a feel for the API and then inject data (API injection) into the data flow
API Injection
- When an attacker inputs their own data into an API flow
- An example of an on-path attack
- Ex: An attacker might be watching a bank transfer and inject their own data and have the money transferred
DDoS and API security
- Distributed Denial of Service
- One bad API call can bring down an entire service
API Security
- Authentication is limit API access and thus vulnerability
- Only use API authentication over encrypted (secure) protocols
- Authorization - API should be limited based on a user’s roles/ privileges
- users should have limited roles
- Ex: read only user should not be able to make changes
WAF
- Web Application Firewall
- Apply rules to API communication
- Web based or API based applications, can configure firewall to monitor all communication to a particular user’s data
Site resiliency
- Need to have recovery site prepared
- Data needs to be synchronized
- If a disaster is called, need to have processes for failover
- can take days, weeks longer
- Need process and procedures for moving to the disaster sites and back to the original location
Hot Site
- An exact replicate of production environment
- duplicates everything (infrastructure, hardware, software, etc.)
- If you purchase something new for production environment, you’ll need to buy another for your hot site
- Synchronization is key (applications and software are constantly updated, automated replication)
- real time updates (with high speed connections) or maybe periodic updates that synchronize real time data center and hot site
- If everything is in sync, it should be easy to ‘flip the switch’ if disaster occurs
Cold Site
- Opposite of hot site
- Room with racks, none of your data, equipment, applications, etc.
- You have to bring it all with you
- You have to bring the ppl with you too
Warm Site
- Somewhere in between hot and cold
- Usually have racks and some equipment that you can get up and running in a relatively short time
- big room with rack space, you bring the software, the hardware is ready and waiting
- what is available is usually part of disaster recovery contract (how much you pay, what’s available)
- more that’s available, higher the bill
Honeypot
- System or series of systems that’s meant to look really attractive to an attacker (and trap them there)
- Attacker is most likely not a human
- Can see what their recon is like
- It’s often a virtual world meant to spoof your actual system
- software Tools you can use to set up honepots: (Kippo, Google Hack Honeypot, Wordpot)
- constant battle with this software to see if it can accurately discern real from fake data
- Attackers will perform checks to see if it’s honey pot, so you’re honeypot must be good
Honeynet
- Multiple honeypot on a network
- More than one source of information
- Stop spammers: https://projecthoneypot.org
Honeyfiles
- Attractive bait you want the attacker to go after
- Ex: a file called passwords.txt
- If file is access by attacker, then you can get a notification
- A virtual bear trap
Fake Telemetry
- Attackers will add fake telemetry to a machine learning model, in order to make their malware look benign
- after training is over then they can send their malicious software
DNS Sinkhole
- (opposite of a DNS) Instead, it’s a DNS that hands out incorrect or invalid IP addresses when one is requested
- Blackhole DNS
- if an attacker implements a DNS sinkhole then they can redirect users to a malicious site (or create a DNS)
- More commonly used to provide information for a security professional (redirect known malicious domains to a benign IP address, watch for any users hitting that address, know that those devices are infected)
- Useful tool for security professionals
- often integrated with an intrusion prevention device (firewall), if someone tries to communicate out to a malicious site, the sinkhole will redirect to a good site and trigger an alert so security team will know a device with malware (device also won’t be able to communicate out to command and control) and IT can clean device.
- Remember a DNS (Domain Name Service) is the service that hands out IP addresses that are associated with FQDN (fully qualified domain names)
FQDN
- Fully qualified Domain Name
- What a DNS (Domain Name Service) will verify before handing out IP addresses
Intrusion Prevention Device
- Next generation firewall