Chapter 02: System and Network Architecture Flashcards
Serverless Computing
In a broad sense, this is cloud computing, but it also refers to FaaS (function as a service)
FaaS
* A cloud service model that supports severless software architecture by provisioning runtime containers in which code is executed in a particular programming language
Serverless computing relies on a system that executes functions as they’re called—when an action needs to be performed, the function is run (a functional call)
EX: AWS Lambda, Google’s App Engine, Azure
The same types of security controls used for software dev and cloud computing environments (access controls and rigts) need to be applied to the FaaS environment
Monitoring and resource management are also necessary for secure deployment
Advantages include:
* Reduced costs (billed as-is vs constantly running)
* Reduced server maintenance and management overhead
* Eliminates the need to manage physical or virtual servers
* No patching, admininistration, or file system monitoring
Security concerns:
* Ensure that the clients accessing the services haven’t been compromised
* The devs are the big ones here, not the end-users at home
* Focused on the code to make sure it’s secure more than anything
NOTE: Severless depends on orchestration
Cloud Deployment Models
Public Cloud
* A service provider makes resources available to the end users over the internet
* Deployed for shared use by multiple independent tenants
* Public clouds provide solid redundancy and availability
* Only have logical access
* EX: AWS is a public cloud
Private Cloud
* Where an org creates its own cloud environment that only it can utilize as an internal enterprise resource
* Can be hosted internally or externally
* You own it, have access to it, and can touch it physically and logically
* Private should be your choice when security is more important than cost
* EX: AWS GovCloud (US)—servers purchased just for the government
Community Cloud
* Uses shared resources and costs among different orgs that have common service needs
* Deployed for shared use by cooperating tenants
* These are secure when the orgs involved have strong interoperability agreements (I want level 10 security, but you want level 2—we need a baseline everyone can work with)
Hybrid Cloud
* Combines public, private, and community clouds as well as on-prem infrastructure to meet an org’s needs
* Challenges of Hybrid: Greater complexity, absence of data redundancy, demonstrating compliance, security management
Multicloud
* Cloud consumer uses multiple public cloud services
* EX: Using Google Cloud, AWS, and Azure
Virtualization
The use of software to run virtual computers on underlying real hardware
You can run multiple systems, each running multiple OS, all of which act as if they’re on their own hardware
This provides additional control of resource usage and what hardware is presented to the guest OS
Allows for efficient use of the underlying hardware because you can leverage shared resoruces
VDI
Virtual Desktop Infrastructure
Virtualization is used to implement VDI, which runs desktop OS on central hardware, and then streams the desktops across the network to systems
The security challenge is in determining how to monitor, secure, and respond to issues in a virtual environment
Dion’s Notes
* A virtualization implementation that separates the personal computing environment from a user’s physical computer
Container Security
Containerization platforms share many security considerations with virtualization platforms
They must enforce isolation between containers to prevent operational and security issues that might occur if an app running in one container is able to accidentally or intentionally interact with resoruces assigned to another container
Traditional host-based security may work for the underlying containerization server, but the containers themselves must be addressed differently
Since many containers run on the same server, threats to the host OS can impact containerized services
Tools exist to sign container images, and monitor and patch containers
Traditional hardening, application and service monitoring, and auditing tools can be useful as well
NOTE: When addressing containerized systems, think about the shared underlying host as well as the rapid deployment models typically used with containers
Security must be baked into the service and software development life cycle as well as the systeam maintenance and management process
Page 39 + 40 for in depth
Containerization
An alternative to virtualizing an entire system whereby apps are permitted to run in their own environment with their own required components (libraries, confg files, dependancies) in a dedicated container
EX: Kubernetes and Docker
Containers provide app-level virtualization
Instead of creating complex virtual machines that require their own OS, containers package apps and allow them to be treated as units of virtualization that become portable across OS and hardware platforms
Common System Hardening Practices
System hardening is the process where a host or other device is made more secure through the reduction off that device’s attack surface area
- Updating and patching the system
- Removing unnecessary software and services
- Restricting and logging admin access
- Controlling the creation of new accounts
- Enabling logging and using appropriate monitoring
- Using capabilities like disk encryption and secure boot
The CIS provides a full range of hardening guides and config benchmarks for common OS: https://www.cisecurity.org/benchmark
Dion’s 10 Hardening Best Practices Checklist
1. Remove or disable devices that aren’t needed or used
2. Install OS, application, firmware, and driver patches regularly
3. Uninstall all unnecessary network protocols—only have ports open for things you need
4. Uninstall or disable all unnecessary services and shared folders
5. Enforce ACLs on all system resources
6. Restrict user accounts to the least privilege needed
7. Secure the local admin or root account by renaming it and changing password
8. Disable unnecessary default user and group accounts
9. Verify permissions on system accounts and groups
10. Install antimalware software and update the definitions regularly
5 Main Root Keys in the Registry
- HKEY_CLASSES_ROOT (HKCR): COM object registration information, associates files type with programs
- HKEY_LOCAL_MACHINE (HKLM): System information, including scheduled tasks and services
- HKEY_USERS (HKU): Information about user accounts
- HKEY_CURRENT_USER (HKCU): Information about the currently logged-in user
- HKEY_CURRENT_CONFIG (HKCC): Current local hardware profile information storage
Each root key listed here has Registry hives, which are groups of keys and values that are connected with the root keys
Each key can have values including:
* Strings
* Binary data
* Numeric data
* Links to other Registry keys
* Windows-specific component data
The Windows Registry
This is a database that contains OS settings
Programs, services, drivers, and the OS itself rely on info stored in the Registry, which makes it a ctirical resource
It also makes it a frequent target for attackers because it’s useful for persistence
Configuration Files
Know where both Linux and Windows commonly store these critical config files
- Windows: Often sotred in the Registry, but additional config info might be in C:\ProgramData C:\Program Files
- Linux: Commonly stored in the /etc directory, but may be stored in other locations depending on service or program
- MacOS: The exam doesn’t focus on Mac, but they’re stored in ~/Library/Preferences
System Processes
The core processes for an OS
Some vary from OS to OS, but they tend to share similar functions
- Windows: The core system process is the NT kernel, which is found in C:\Windows\System32\notskrnl.exe and always has a PID of 4
Other Windows processes include:
* The Registry process
* Memory compression
* Session manager subsystem (smss.exe)
* Windows subsystem process (crss.exe)
* Services control manager (services.exe)
* Windows logon process (winlogon.exe)
* Windows initialization process (wininit.exe)
NOTE: Focus on understanding the basic concept of system processes for the exam:
* They’re critical parts of the OS
* Attackers often name proceses to look similar to legit processes in an attempt to conceal malware
* Attackers target them to gain privileged access to the OS
Hardware Architecture Security
The underlying hardware architecture of the systems that OS and software run on can have an impact on security operations in many ways
One of the most common impacts is that malware may not run on some hardware at all
While most computers run on x86 instruction set CPUs from AMD and Intel, there are an increasing number of computers and devices that that use Advanced RISC Machine (ARM) or other CPUs that don’t implement the x86 instruction set
This means that software that is not compiled and intended for other architectures is unlike to work with them
- EX: Apple M1 and M2 chips are non-x86, ARM-based architecture
Using an alternate hardware architecture isn’t a guarantee for security since attackers build malware to attack multiple hardware architectures
Still, always know what hardware architecture systems you’re responsible for defending
x86 Instruction Set
The x86 instruction set refers to the set of instructions that x86-compatible microprocessors support, which are usually part of an executable program, often stored as a computer file and executed on the processor
Importance of Time Synchronization for Logging
Time sync between systems is critical to log analysis
That’s because events and incidents often result in logs in multiple locatios or from multiple servers or services needing to be correlated
If time isn’t properly and accurately synced, events won’t appear in the correct order or at the right times
NTP
Network Time Protocol (Port 123) and NTP servers allow for easy time syncrhonization
As part of your regular reviews of systems and services, you must always ensure that time sync is happening, and that it’s correct
Windows and Linux both have their own NTP guides that should be known for the job
Logging Levels
Network device log files often have log levels associated with them
More or less, they tend to map to Cisco’s log levels:
* 0: Emergencies / Device shutdown due to failure
* 1: Alerts / Temperature limit exceeded
* 2: Critical / Software failure
* 3: Errors / Interface down message
* 4: Warning / Configuration change
* 5: Notifications / Line protocal up/down
* 6: Information / ACL violation
* 7: Debugging / Debugging messages
Understand log levels and what setting a log level can mean for data capture
If you set a logging level that doesn’t catpure the data you need, you can miss important information
If you set overly detailed log levels, like level 7, it’ll provide an overwhelming flood of detail that isn’t useful
General Logging Considerations
- Logs should contain enough information to be useful and should be able to be interpreted in useful ways, and so must contain both meaning and context
- Logs should be protected so they can’t be changed
- Logs should be sent to a central location where they can be stored, analyzed, and reported on
- Logs should be validated to ensure they contain the information that would be needed in the event of an issue or incident
- Logs should be checked as part of normal system monitoring to ensure that systems that should send logs are doing so
- Unnecessary log information should be avoided to conserve space and resources
- Log retention policies and practices should be implemented as appropriate for the org and systems
On-Premises Network Architecture
The routers, switches, security devices, cabling, and all other network components that make up a traditional network
Common elements of a security design linclude:
* Firewalls that control traffic flow between networks or systems
- IPS and IDS
- Content filtering and caching devices that contorl what info passes through protected devices
- NAC technology that controls which devices are able to connect to the network, assess the security state of devices, or require other information before allowing a connection
- Network scanners that can identify systems and gather information about them, includig the services they’re running, patch levels, and other details
- UTM devices that combine a number of these services like firewalls, IDS, IPS, content filters, etc
Cloud Network Architecture
Unlike on-premises, cloud architectures aren’t always available for security pros to configure, test, or control
This demands a different approach for securing cloud services
Security for SaaS and PaaS is usually handled through contractual obligations
IaaS providers like AWS, Azure, Google, etc provide more access to infrastructure, so some traditional security concerns around OS config, management, and patching applies
You can take additional action to ensure your org’s security by accessing third-party security audit information like an SSAE-16 Type 1 or Type 2 report
You can also conduct a security assessment to determing whether the vendor meets your own security best practices
Shared risk assessment tools from Shared Assessments .org can help conduct an assessment before engaging with a cloud or outsourced IT vendor
Always ensure your contracts cover any legal or reulatory issues that could impact your outsourcing solutions
SaaS
* Provides all the hardware, OS, software, and apps needed for a complete app service to be delivered
* Consumer is responsible for app security, account provisioning, and authorizations
IaaS
* Provides all the hardware, OS, and backend software needed in order to develop software or services
* Consumer is responsible for security of platforms and apps
* CSP are responsible for CIA of the hardware in the resource pool
PaaS
* Provides the org with the hardware and software needed for a specific service to operate
* CSP are responsible for giving you everything except app and data
* All the consumer needs to do is code the application and bring their data
* Always consider access control, load balancing, failover, privacy, and protection of data
* Always encrypt data stored in a third party PaaS solution
Hybrid Network Architecture
Combines on-premises and cloud infrastructure and systems
This can introduce complexities as each distinct environment must be secured and have a security model that’s appropriate to the entire infrastructure
These are common architectures as orgs migrate from on-premises to cloud