Comparing and Contrasting Security Controls
Escalation
An incident may be judged too critical to continue to be managed by the first responder. The process by which more senior staff become involved in the management of an incident is called escalation. Escalation may also be necessary if no response is made to an incident within a certain time frame.
SIEM
Technology solutions for managing incidents use automated log analysis and intrusion detection routines to drive an alerting and reporting system, Security Information and Event Management (SIEM). A SIEM can also be used to script the standard actions that responders should take for several different scenarios (a playbook).
Incident Types/Category Definitions
identified incidents must be assessed for severity and prioritized for remediation. There are several factors that can affect this process: Data integrity—the most important factor in prioritizing incidents will often be the value of data that is at risk. Downtime—another very important factor is the degree to which an incident disrupts business processes. An incident can either degrade (reduce performance) or interrupt (completely stop) the availability of an asset, system, or business process. If you have completed an asset inventory and a thorough risk assessment of business processes (showing how assets and computer systems assist each process), then you can easily identify critical processes and quantify the impact of an incident in terms of the cost of downtime. Economic/publicity—both data integrity and downtime will have important economic effects, both in the short term and the long term. Short term costs involve incident response itself and lost business opportunities. Long-term economic costs may involve damage to reputation and market standing. Scope—the scope of an incident (broadly the number of systems affected) is not a direct indicator of priority. A large number of systems might be infected with a type of malware that degrades performance, but is not a data breach risk. This might even be a masking attack as the adversary seeks to compromise data on a single database server storing top secret information. Detection time—research has shown that the existence of more than half of data breaches are not detected for weeks or months after the intrusion occurs, while in a successful intrusion data is typically breached within minutes. This demonstrates that the systems used to search for intrusions must be thorough and the response to detections must be fast. Recovery time—some incidents require lengthy remediation, as the system changes required are complex to implement. This extended recovery period should trigger heightened alertness for continued or new attacks. For a listing of the US Federal agency incident categories, you can visit https://www.us-cert.gov/sites/default/files/publications/Federal_Incident_Notification_Guidelines.pdf. As a preparatory activity, it is also useful for the CIRT to develop profiles or scenarios of typical incidents. This will guide investigators in determining appropriate priorities and remediation plans. A playbook (or runbook) is a data-driven procedure to assist junior analysts in detecting and responding to quite specific cyber threat scenarios (phishing attempt, .RAR file data exfiltration, connection to a blacklisted IP range, and so on). The playbook starts with a report or alert generated by a security tool and query designed to detect the incident and identifies the key detection, containment, and eradication steps to take.
Frameworks and Reference Architectures
A cybersecurity framework is a list of activities and objectives undertaken to mitigate risks. The use of a framework allows an organization to make an objective statement of its current cybersecurity capabilities, identify a target level of capability, and prioritize investments to achieve that target. This is valuable for giving a structure to internal risk management procedures and also provides an externally verifiable statement of regulatory compliance.
Data Breach
A data breach is where an attack succeeds in obtaining information that should have been kept secret or confidential. Once data has been stolen in this way, it is virtually impossible to prevent further copies of it being made, though it may be possible to act against those that try to publish it. It has to be assumed, however, that the data stolen is no longer confidential. It is critical to identify precisely what has been stolen, though often this is a difficult enough task in itself. Security systems must be reanalyzed and re-secured, so that things like passwords are changed, even if there is no direct evidence that they have been compromised. Note that in this context the suspicion of data theft may be enough to have to trigger reporting procedures. Even if it is only suspected that customer passwords or credit card numbers have been stolen (for instance), customers must be notified so that they can take steps to re-secure other online accounts or financial accounts.
Security Control Types
A security control (or countermeasure) is something designed to make a particular asset or information system secure (that is, give it the properties of confidentiality, integrity, availability, and non-repudiation). Security controls can be classified according to their type or function. Controls can be divided into three broad classes: Administrative/management—controls that determine the way people act, including policies, procedures, and guidance. For example, annual or regularly scheduled security scans and audits can check for compliance with security policies. Technical—controls implemented in operating systems, software, and security appliances. Examples include Access Control Lists (ACL) and Intrusion Detection Systems. Physical—controls such as alarms, gateways, and locks that deter access to premises and hardware are often classed separately. Types: Preventive—the control physically or logically restricts unauthorized access. A directive can be thought of as an administrative version of a preventive control. Deterrent—the control may not physically or logically prevent access, but psychologically discourages an attacker from attempting an intrusion. Detective—the control may not prevent or deter access, but it will identify and record any attempted or successful intrusion. Corrective—the control responds to and fixes an incident and may also prevent its reoccurrence. Compensating—the control does not prevent the attack but restores the function of the system through some other means, such as using data backup or an alternative site. As no single security control is likely to be invulnerable, it is helpful to think of them as delaying or hampering an attacker until the intrusion can be detected. The efficiency of a control is a measure of how long it can delay an attack. NIST's classifications for security controls, defined in "SP800-53 Recommended Security Controls for Federal Information Systems and Organizations" (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf).
Containment Phase
As incidents cover such a wide range of different scenarios, technologies, motivations, and degrees of seriousness, there is no standard approach to containment or incident isolation. Some of the many complex issues facing the CIRT are: -What damage or theft has occurred already? -How much more could be inflicted and in what sort of time frame (loss control)? -What countermeasures are available? -What are their costs and implications? -What actions could alert the attacker to the fact that the attack has been detected? -What evidence of the attack must be gathered and preserved?
Reporting Requirements
As well as attempting to identify the attacker, a data breach will normally require that affected parties be notified, especially if personally identifiable information (PII) or account security information is involved. As well as data protection legislation, many industries have strict regulations regarding the safe processing of data and will set out reporting requirements for notifying affected customers as well as the regulator. The regulator will also require evidence that the systems that allowed the breach have been improved.
Benchmarks and Secure Configuration Guides
At a system level, the deployment of servers and applications is covered by benchmarks and secure configuration guides. Platform/Vendor-specific Guides Most vendors will provide guides, templates, and tools for configuring and validating the deployment of network appliances, operating systems, web servers, and application/database servers. General Purpose Guides There is also detailed guidance available from several organizations to cover both vendor-neutral deployments and to provide third-party assessment and advice on deploying vendor products. The Open Web Application Security Project (https://owasp.org) is a not-for-profit, online community that publishes several secure application development resources, such as the Top 10 list of the most critical application security risks. OWASP has also developed resources, such as the Zed Attack Proxy and Webgoat (a deliberately unsecure web application), to help investigate and understand penetration testing and application security issues. Department of Defense Cyber Exchange provides hardening guidelines for a variety of software and hardware solutions (https://public.cyber.mil). National Checklist Program (NCP) by NIST provides checklists and benchmarks for a variety of operating systems and applications (https://nvd.nist.gov/ncp/repository). The SANS Institute (https://sans.org) is a company specializing in cybersecurity and secure web application development training and sponsors the Global Information Assurance Certification (GIAC). The SANS website publishes a huge amount of research, white papers, and best practice guidance. The Center for Internet Security (https://cisecurity.org) is a not-for-profit organization (founded partly by SANS). It publishes the well-known "Top 20 Critical Security Controls" (or system design recommendations). CIS also produces benchmarks for different aspects of cybersecurity. For example, there are benchmarks for compliance with IT frameworks and compliance programs, such as PCI DSS, NIST 800-53, SOX, and ISO 27000. There are also product-focused benchmarks, such as for Windows Desktop, Windows Server, macOS, Linux, Cisco, web browsers, web servers, database and email servers, and VMware ESX.
Regulatory Compliance Requirements
Due diligence is a legal term meaning that responsible persons have not been negligent in discharging their duties. In the US, for example, the passage of the Sarbanes-Oxley Act (SOX) has mandated the implementation of risk assessments, internal controls, and audit procedures. The Computer Security Act (1987) requires federal agencies to develop security policies for computer systems that process confidential information. In 2002, the Federal Information Security Management Act (FISMA) was introduced to govern the security of data processed by federal government agencies. FISMA compliance is audited through the risk management framework (RMF), developed by NIST. Agencies can go through a process of Assessment & Authorization (A&A) to demonstrate compliance with the RMF. Security standards and controls to ensure customer privacy in particular industries, notably financial services (the Gramm-Leach-Bliley Act [GLBA]) and healthcare (the Health Insurance Portability and Accountability Act [HIPAA]). Payment Card Industry Data Security Standard (PCI DSS) governing processing of credit card payments. Some regulations have specific cyber-security control requirements; others simply mandate "best practice" (as represented by a particular industry or international framework).
Eradication of Malware
Eradication of malware or other intrusion mechanisms and recovery from the attack will involve several steps: Reconstitution of affected systems—either remove the malicious files or tools from affected systems or restore the systems from secure backups. -If reinstalling from baseline template configurations, make sure that there is nothing in the baseline that allowed the incident to occur! If so, update the template before rolling it out again. Re-audit security controls—ensure they are not vulnerable to another attack. This could be the same attack or from some new attack that the attacker could launch through information they have gained about your network. -If your organization is subjected to a targeted attack, be aware that one incident may be very quickly followed by another. Ensure that affected parties are notified and provided with the means to remediate their own systems. For example, if customers' passwords are stolen, they should be advised to change the credentials for any other accounts where that password might have been used (not good practice, but most people do it).
Incident Response Plan (IRP)
From the policies, a formal Incident Response Plan (IRP) listing the procedures, contacts, and resources available to responders should be developed.
Identification Phase
Identification/detection is the process of collating events and determining whether any of them should be managed as incidents or as possible precursors to an incident; that is, an event that makes an incident more likely to happen. There are multiple channels by which events or precursors may be recorded: -Using log files, error messages, IDS alerts, firewall alerts, and other resources to establish baselines and identifying those parameters that indicate a possible security incident. -Comparing deviations to established metrics to recognize incidents and their scopes. -Manual or physical inspections of site, premises, networks, and hosts. -Notification by an employee, customer, or supplier. -Public reporting of new vulnerabilities or threats by a system vendor, regulator, the media, or other outside party. It is wise to provide for confidential reporting so that employees are not afraid to report insider threats, such as fraud or misconduct "this is a whistleblower". It may also be necessary to use an "out-of-band" method of communication so as not to alert the intruder that his or her attack has been detected.
Quarantine and Device Removal
If further evidence needs to be gathered, the best approach may be to quarantine or sandbox the affected system or network. This allows for analysis of the attack and collection of evidence using digital forensic techniques. This can only be done if there is no scope for the attacker to cause additional damage or loss. There are great practical problems in establishing an effective quarantine, however. It may be possible to redirect the attacker into some kind of honeypot or honeynet or to use a firewall or intrusion detection to limit wider access. It may also be possible to restrict the attack by changing account passwords or privileges or to apply patches to hosts not yet affected by the attack. Another option is to remove an affected device from the system it is attached to ("pull the plug"). This will prevent the attacker from widening the attack but may alert him or her to the fact that the attack has been detected. A sophisticated attacker may have retaliatory attacks prepared to meet this sort of contingency.
Incident Response Procedures
Incident management or incident response policy is the procedures and guidelines for dealing with security incidents. An incident is where security is breached or there is an attempted breach; NIST describes an incident as "the act of violating an explicit or implied security policy." However, incident response is also one of the most difficult areas of security to plan for and implement because its aims are often incompatible: -Identify and prioritize all incidents that pose risk without overloading the security team. -Re-establish a secure working system. -Preserve evidence of the incident with the aim of prosecuting the perpetrators. -Prevent reoccurrence of the incident. The NIST Computer Security Incident Handling Guide special publication (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) identifies the following stages in an incident response lifecycle: Preparation—making the system resilient to attack in the first place. This includes hardening systems, writing policies and procedures, and establishing confidential lines of communication. It also implies creating a formal incident response plan. Identification—determining whether an incident has taken place and assessing how severe it might be, followed by notification of the incident to stakeholders. Containment, Eradication, and Recovery—limiting the scope and impact of the incident. The typical response is to "pull the plug" on the affected system, but this is not always appropriate. Once the incident is contained, the cause can then be removed and the system brought back to a secure state. Lessons learned—analyzing the incident and responses to identify whether procedures or systems could be improved. It is imperative to document the incident.
Communication Processes
It is imperative that adversaries not be alerted to detection and remediation measures about to be taken against them. The team requires an "out-of-band" or "off-band" communication method that cannot be intercepted. Using corporate email or VoIP runs the risk that the adversary will be able to intercept communications. For file and data exchange, there should be a messaging system with end-to-end encryption, such as Off-the-Record (OTR), Signal, or WhatsApp, or an external email system with message encryption (S/MIME or PGP). These need to use digital signatures and encryption keys from a system that is completely separate from the identity management processes of the network being defended.
Cyber Incident Response Team (CIRT) Roles and Responsibilities
Large organizations will provide a dedicated cyber incident response team (CIRT) or computer security incident response team (CSIRT) as a single point-of-contact for the notification of security incidents. Another important consideration is availability. Incident response will typically require 24/7 availability, which will be expensive to provide. It is also worth considering that members of the CIRT should be rotated periodically to preclude the possibility of infiltration. For major incidents, expertise and advice from other business divisions will also need to be called upon: Legal—it is important to have access to legal expertise, so that the team can evaluate incident response from the perspective of compliance with laws and industry regulations. It may also be necessary to liaise closely with law enforcement professionals, and this can be daunting without expert legal advice. HR (Human Resources)—incident prevention and remediation actions may affect employee contracts, employment law, and so on. Incident response requires the right to intercept and monitor employee communications. PR (Public Relations)—the team is likely to require public relations input, so that any negative publicity from a serious incident can be managed. Some organizations may prefer to outsource some of the CIRT functions to third-party agencies by retaining an incident response provider. External agents are able to deal more effectively with insider threats.
Defense in Depth
Layered security is typically seen as the best protection for systems security because it provides defense in depth. The idea is that to fully compromise a system, the attacker must get past multiple security controls, providing control diversity. Control diversity means that the layers of controls should combine different classes of technical and administrative controls with the range of control functions (prevent, deter, detect, correct, and compensate). Defense in depth, established by deploying a diverse range of security controls, could mitigate the numerous risks inherent in this scenario: -User training (administrative control) could ensure that the media is not left unattended on a desk and is not inserted into a computer system without scanning it first. -Endpoint security (technical control) on the laptop could scan the media for malware or block access automatically. -Security locks inserted into USB ports (physical control) on the laptop could prevent attachment of media without requesting a key, allowing authorization checks to be performed first. -Permissions restricting Alan's user account (technical control) could prevent the malware from executing successfully. -The use of encrypted and digitally signed media (technical control) could prevent or identify an attempt to tamper with it. -If the laptop were compromised, intrusion detection and logging/alerting systems (technical control) could detect and prevent the malware spreading on the network.
Lessons Learned Phase
Once the attack or immediate threat has been neutralized and the system restored to secure operation, some follow-up actions are appropriate. The most important is to review security incidents to determine their cause and whether they were avoidable. This can be referred to as "lessons learned." It is also necessary to review the response to the incident, to determine whether it was appropriate and well implemented. A lessons learned activity will usually take the form of a meeting with the CIRT and management to finalize the incident timeline. This meeting should take place within two weeks of the incident so that events are fresh in everyone's minds. The meeting: -Identification of the problem and scope, as well as the steps taken to contain, eradicate, and recover. -The effectiveness of the IRT and the incident response plan (IRP), particularly what worked well and what needs improvement. -Completion of the incident documentation to provide a comprehensive description of the incident and how the IRT responded to it. You need to consider obligations to report the attack. It may be necessary to inform affected parties during or immediately after the incident so that they can perform their own remediation. It may be necessary to report to regulators or law enforcement. You also need to consider the marketing and PR impact of an incident. This can be highly damaging and you will need to demonstrate to customers that security systems have been improved.
Preparation Phase and Incident Response Plan
Preparing for incident response means establishing the policies and procedures for dealing with security breaches and the personnel and resources to implement those policies.
Incident Response Exercises
Running test exercises helps staff develop competencies and can help to identify deficiencies in the procedures and tools.
Eradication & Recovery Phases
There are often no right answers to the question of what mitigation steps are appropriate to contain, eradicate, and recover from an incident. The response team may have to choose the "least bad" option. While prosecution of the offenders may be important, business continuity is likely to be the team's overriding goal. Again though, every situation is different and if there is sufficient time, a full evaluation of the different issues should be made so that the best response can be selected. Some sample responses to incidents include the following: Investigation and escalation—the causes or nature of the incident might not be clear, in which case further (careful) investigation is warranted. Containment—allow the attack to proceed, but ensure that valuable systems or data are not at risk. This allows collection of more evidence, making a prosecution more likely and also gathering information about the way the attack was perpetrated. Hot swap—a backup system is brought into operation and the live system frozen to preserve evidence of the attack. Prevention—countermeasures to end the incident are taken on the live system (even though this may destroy valuable evidence).
Cybersecurity Frameworks
These frameworks are non-regulatory in the sense that they do not attempt to address the specific regulations of a specific industry but represent "best practice" in IT security governance generally. The National Institute of Standards and Technology (NIST) Cybersecurity Framework (https://nist.gov/cyberframework) is a relatively new addition to the IT governance space and distinct from other frameworks by focusing exclusively on IT security, rather than IT service provision more generally. It is developed for a US audience and focuses particularly on US government, but its recommendations can be adapted for other countries and types of organizations. The International Organization for Standardization (ISO) has produced a cybersecurity framework in conjunction with the International Electrotechnical Commission (IEC). The framework was established in 2005 and revised in 2013. Unlike the NIST framework, ISO 27001 must be purchased (https://iso.org/standard/54534.html). ISO 27001 is part of an overall 27000 series of information security standards. The Control Objectives for Information and Related Technologies (COBIT) is an overall IT governance framework with security as a core component. The framework was first published in 1996 and version 5 was released in 2012. COBIT is published by ISACA and like the ISO is a commercial product, available through APMG International (https://apmg-international.com/product/cobit-5). The Sherwood Applied Business Security Architecture (SABSA), maintained by the SABSA Institute (https://sabsa.org), is a methodology for providing information assurance aligned to business needs and driven by risk analysis. The SABSA methodology is designed to be applicable to different types of organizations and scalable for use on small-scale projects through to providing overarching enterprise information assurance. The methodology is applied using a lifecycle model of strategy/planning, design, implementation, and management/measurement.
First Responder
When a suspicious event is detected, it is critical that the appropriate person on the CIRT be notified so that they can take charge of the situation and formulate the appropriate response. This person is referred to as the first responder. This means that employees at all levels of the organization must be trained to recognize and respond appropriately to actual or suspected security incidents. A good level of security awareness across the whole organization will reduce the incidence of false positives and negatives. For the most serious incidents, the entire CIRT may be involved in formulating an effective response. It is important to provide redundancy in terms of personnel that can respond to an incident (succession planning). Consider a scenario in which a key staff member cannot be contacted; is there a backup option? This scenario also illustrates the importance of maintaining documented procedures.
Analysis and Incident Identification
When notification has taken place, the CIRT or other responsible person(s) must analyze the event to determine whether a genuine incident has been identified and what level of priority it should be assigned. Analysis will depend on identifying the type of incident and the data or resources affected (its scope and impact). At this point, the incident management database should have a record of the event indicators, the nature of the incident, its impact, and the incident investigator responsible. The next phase of incident management is to determine an appropriate response.
Guidelines for responding to security incidents
When responding to security incidents: -If an IRP exists, then follow the guidelines outlined within it to respond to the incident. -If an IRP does not exist, then determine a primary investigator who will lead the team through the investigation process. -Determine if the events actually occurred and to what extent a system or process was damaged. -Try to isolate or otherwise contain the impact of the incident. -Document the details of the incident.
Vendor diversity
you should consider the advantages of leveraging vendor diversity. Vendor diversity means that security controls are sourced from multiple suppliers. Some disadvantages of single vendor could include the following: Not obtaining best-in-class performance—one vendor might provide an effective firewall solution, but the bundled malware scanning is found to be less effective. Less complex attack surface—a single vulnerability in a supplier's code could put multiple appliances at risk in a single vendor solution. A threat actor will be able to identify controls and possible weaknesses more easily. Less innovation—dependence on a single vendor might make the organization invest too much trust in that vendor's solutions and less willing to research and test new approaches.
