Section 1: Preparation
Incidents happen to us every day - whether it's forgetting a password, a child leaving their lunch behind, or a computer failing to print. These minor events disrupt our day but are generally manageable. Security incidents, however, tend to have a more significant impact.
Different organizations define a security incident in various ways. NIST describes an incident as a "violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices." While this definition is accurate, I find it somewhat limited.
From my experience, a security incident is any event - whether intentional or accidental - that deviates from normal operations and negatively affects business processes, customers, investors, stakeholders, or employees. This expands the NIST definition to encompass violations of policies, regulations, laws, or ethical standards.
Put simply, an incident is anything that compromises the confidentiality, integrity, or availability (CIA) of data or the systems supporting these business operations. Confidentiality ensures that only authorized individuals or applications have access to sensitive information. Integrity refers to the accuracy and authenticity of the data. Availability guarantees that information is accessible to authorized entities when and where it is needed for legitimate business operations.
Incident response is a crucial component of a broader incident management program. The goal of incident management is to prepare for the various types of incidents and respond effectively when they hit. A robust incident management program generally contains four key objectives:
1. Developing and managing an incident management policy and supporting procedures.
2. Creating, training, and managing an incident response team.
3. Preparation, including:
- Strategic threat intelligence
- Vulnerability management
- Risk management
4. Incident response, aimed at minimizing or preventing business impact.
Section 1.01 Policy, Procedures, and Team
The incident management policy is the cornerstone of your organization's preparedness and response capabilities in the face of unwanted or unexpected events. A template for an incident management policy can be downloaded at this link. This policy establishes the framework for an incident management program and assigns responsibilities for both incident management and response.
In the following sections, I discuss creating an incident response team, developing an incident response plan (IRP), and defining its procedures. For now, it's essential to understand the importance of having documented and up-to-date incident response procedures. You don't want to encounter an incident without a clear strategy for mitigating or precenting negative business impacts.
Section 1.02: Strategic Threat Intelligence
Strategic Threat Intelligence (STI) equips your organization with insights into likely threats, as well as the tools and techniques used by potential adversaries. A threat agent refers to the specific actors or instances of a threat. For example, the general threat might be the theft of customer payment information through exploitation of vulnerabilities, while a threat agent would be a cybercriminal using specific tools and techniques to exploit those weaknesses and steal data.
Without a thorough understanding of how an organization can be attacked, conducting a comprehensive risk assessment is impossible. Fortunately, information on potential threats and threat agents can be sourced from:
- Government and Public Sources:
- Your Vendors
- Intrusion Prevention System (IPS) vendor
- Security Information and Event Management (SIEM) vendor
- Threat analytics provider
- Microsoft
- Apple
Understanding both the broader landscape of potential threats and the specific agents that may target your organization is crucial for building a robust security posture.
Section 1.03 Vulnerability Management
Managing vulnerabilities will always be an ongoing process that allows you to identify and assess risks associated with specific threat agents. For instance, you might uncover a missing patch during a vulnerability scan for Microsoft Windows that is actively being exploited by known threat actors. Another example could involve not blocking nonessential SQL Server traffic through a firewall or leaving a VLAN access control list (ACL) improperly configured. Vulnerabilities typically stem from the following factors:
- Insecure configuration of operating systems, network devices, and applications
- Poor coding practices or developer oversights and/or mistakes
- Lack of user security training and awareness
- Weak authentication, authorization, and access control mechanisms and measures
(a) Insecure Coding and Configurations
Operating systems like Windows and Windows Server come with security baselines provided by Microsoft, which serve as a good starting point for securing these OS. Similarly, network device vendors offer best practices for securely configuring their products. This includes security recommendations such as blocking all traffic by default (using a 'deny all' policy), and only allowing necessary traffic for legitimate business operations. Cisco, for example, provides comprehensive guidance for hardening IOS devices here.
Ensuring secure application configurations and reviewing coding practices shouldn't pose significant challenges if your System and Software Development Life Cycle (SDLC) includes risk assessments and security requirements testing. To better integrate security into your SDLC, refer to the NIST SP 800-64 R2 for guidance.
(b) User Security Training and Awareness
Human error is one of the largest vulnerabilities organizations presently face. While relying on users to maintain the confidentiality, integrity, and availability (CIA) of data should be a last resort, it is critical to address this through continuous user security training and awareness. A well-communicated Acceptable User Policy (AUP) template available here forms the foundation of this effort. For a deeper dive into establishing a user security training and awareness program, please refer to the NIST SP 800-50.
(c) Access Control
Controlling access to sensitive information requires rigorous authentication (verifying the identity of the user or application accessing the resources) followed by proper authentication. Authorization ensures that users only have access to the resources they need based on roles and responsibilities, employing principles such as segregation of duties, need-to-know, and least privilege.
- Segregation of Duties: Prevents one individual from completing all tasks associated with a business process, mitigating the risk of unauthorized actions.
- Need-to-Know: Ensures individuals are only granted access to the specific data necessary to perform their assigned duties.
- Principle of Least Privilege (PoLP): Limits the actions users can perform with the data they access.
Here are some examples:
1. When a user logs into the network, their identity is confirmed through authentication.
2. The user is granted access to the payroll system because of their role within the organization, which is determined through coarse authorization.
3. Within the payroll system, the user is granted access to specific data or tasks, such as viewing or updating salary information, based on their role, adhering to segregation of duties (fine-grained authorization).
4. After scheduling a particular task, the user is only allowed to perform specific actions on the data (e.g., view but not edit). This is guided by the principle of least privilege (PoLP), which ensures they can only do what's necessary for their job role.
5. The system ensures that the user can only view the data relevant to their assigned job tasks, following the need-to-know principle, restricting visibility to essential information.
The final component of access control is accountability. This ensures that actions taken by the user are tracked, so you know who accessed which resources, what they did with it, when and how. This is accomplished by logging and auditing system activities regularly.
Access control strength is based on the sensitivity of the resources it protects, which depends on the classification of the data:
- Public: Data that can be accessed by anyone without negative consequences.
- Confidential: Data that would cause moderate harm if compromised.
- Restricted: Data that would cause severe harm if its confidentiality, integrity, or availability is compromised.
All devices that process, store, or transmit data (known as data in transit, or data at rest), based on the most sensitive data they handle. For instance, if a server contains both restricted and public data, the server should be classified as restricted. Critical resources should be protected with stronger access controls, such as multifactor authentication and encryption.
Note: When classifying data of both types (e.g., sensitive and public), the classification always takes highest priority, or severity of the marking of the data (e.g., sensitive data will trump non-sensitive data when combined/top secret data will always trump confidential etc.).
For further exploration of access control practices, refer to Identity Management and Access Control. You can also download a sample segregation of duties matrix and use as a tool for planning and organizing roles.
(d) Vulnerability Identification
To ensure you're not vulnerable to attacks, regularly vulnerability scanning is key. Tools like Nessus are commonly used to scan networks for known vulnerabilities, helping you to stay ahead of potential threats. A strong vulnerability management program goes beyond scanning and also includes penetration testing and third-party security program reviews and audits.
It's essential to start with a vulnerability management policy and detailed procedures (you can download a policy template from here). Additionally, the National Vulnerability Database (NVD) is a valuable resource for tracking known vulnerabilities.
Section Summary:
The main objective of incident management is to prepare for and respond to various types of incidents as they arise. It contains four main core goals:
1. Develop and manage an incident management policy and associated procedures.
2. Create, train, and maintain an incident response team.
3. Focus on preparation, including threat intelligence and risk management.
4. Implement incident response strategies to reduce or prevent business impact.
A security incident is any event, whether intentional or unintentional, that deviates from expected daily operations and can negatively impact business processes, customers, investors, stakeholders, or employees. Essentially, it's anything that threatens the confidentiality, integrity, or availability (CIA) of data or systems supporting business processes.
Rate This Article
Thanks for reading: Incident Response Tutorial - Part I, Sorry, my English is bad:)