Cybersecurity Assessments
Compliance, like everything else in IT, requires effort and the correct configuration. Policies and technologies must work together to align with your goals and the standards you have to follow.
How will you know your backups work if you never attempt to restore them every so often?
How will you know your network is secure if you don’t emulate an attack against it (penetration test) every so often? This is why the validation/certification process is essential.
Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.
1. All data sources and computing services are considered resources. A network may be composed of multiple classes of devices. A network may also have small footprint devices that send data to aggregators/storage, software as a service (SaaS), systems sending instructions to actuators, and other functions. Also, an enterprise may decide to classify personally owned devices as resources if they can access enterprise-owned resources.
2. All communication is secured regardless of network location. Network location alone does not imply trust. Access requests from assets located on enterprise-owned network infrastructure (e.g., inside a legacy network perimeter) must meet the same security requirements as access requests and communication from any other non-enterprise-owned network. In other words, trust should not be automatically granted based on the device being on enterprise network infrastructure. All communication should be done in the most secure manner available, protect confidentiality and integrity, and provide source authentication.
3. Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task. This could mean only “sometime recently” for this particular transaction and may not occur directly before initiating a session or performing a transaction with a resource. However, authentication and authorization to one resource will not automatically grant access to a different resource.
4. Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes. An organization protects resources by defining what resources it has, who its members are (or ability to authenticate users from a federated community), and what access to resources those members need. For zero trust, client identity can include the user account (or service identity) and any associated attributes assigned by the enterprise to that account or artifacts to authenticate automated tasks. Requesting asset state can include device characteristics such as software versions installed, network location, time/date of request, previously observed behavior, and installed credentials. Behavioral attributes include, but not limited to, automated subject analytics, device analytics, and measured deviations from observed usage patterns. Policy is the set of access rules based on attributes that an organization assigns to a subject, data asset, or application. Environmental attributes may include such factors as requestor NIST SP 800-207 ZERO TRUST ARCHITECTURE.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted. The enterprise evaluates the security posture of the asset when evaluating a resource request. An enterprise implementing a ZTA should establish a continuous diagnostics and mitigation (CDM) or similar system to monitor the state of devices and applications and should apply patches/fixes as needed. Assets that are discovered to be subverted, have known vulnerabilities, and/or are not managed by the enterprise may be treated differently (including denial of all connections to enterprise resources) than devices owned by or associated with the enterprise that are deemed to be in their most secure state. This may also apply to associated devices (e.g., personally owned devices) that may be allowed to access some resources but not others. This, too, requires a robust monitoring and reporting system in place to provide actionable data about the current state of enterprise resources.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. This is a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communication. An enterprise implementing a ZTA would be expected to have Identity, Credential, and Access Management (ICAM) and asset management systems in place. This includes the use of multifactor authentication (MFA) for access to some or all enterprise resources. Continual monitoring with possible reauthentication and reauthorization occurs throughout user transactions, as defined and enforced by policy (e.g., time-based, new resource requested, resource modification, anomalous subject activity detected) that strives to achieve a balance of security, availability, usability, and cost-efficiency.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture. An enterprise should collect data about asset security posture, network traffic and access requests, process that data, and use any insight gained to improve policy creation and enforcement. This data can also be used to provide context for access requests from subjects (see Section 3.3.1).
-nist.gov
Anatomy of most (ransomware) attacks:
1. Phishing – Bypasses e-mail filters, domain reputation filters
2. User downloads attachment and runs it – Bypasses antivirus/EDR, user awareness
3. Connection back to the attacker’s C2 server – Bypasses antivirus, EDR, IDS/IPS, domain reputation filters
4. Lateral movement and recon, privilege escalation, exfiltration of data, planting and staging malware – bypasses antivirus, EDR, IDS/IPS, NOC/SOC/anomaly monitoring via SIEM/SOAR (this is a big miss!)
5. Execution of malware, encryption of data – bypasses antivirus, EDR, IDS/IPS, NOC/SOC/anomaly monitoring via SIEM/SOAR
6. Demand of ransom, extortion of any stolen data
How to defend:
- Understanding of the enterprise – all assets, important data, critical infrastructure, business continuity & disaster recovery.
- Vulnerability assessment & penetration testing and an accurate interpretation of these – risk management.
- User awareness & responsibilities – Are the users trained to identify phishing scams, shady attachments, and executables? Are they performing their jobs using best practice methods?
- Good backup solutions – Immutable backup solutions are imperative to the remediation of ransomware.
- Good patching hygiene – Hardware, software and server lifecycles.
- Least privilege – Users can only access what they are supposed to access. No extra programs, ports, protocols, or functionality.
- Network segmentation – Good segmentation prevents easy lateral movement. East and west traffic properly policed. For example, Jane from accounting’s machine can’t touch Joe the officer’s machine.
- The journey to complete Zero Trust starts here.
NIST Wheel
Effective solutions to safeguard your network.
-
- Identify: Risk and Vulnerability Assessment
- Protect: Identity & Access Management, MFA, Policy Control, Network Microsegmentation, NGFW
- Detect: SIEM, SOAR, AI, Behavioral Analytics & Events
- Respond: Back-up & Disaster Recovery, Incident Response plans
- Recover: Restore Network from Backup