The third domain in the SSCP CBK is Risk Identification, Monitoring, and Analysis. This domain accounts for 12% of the SSCP exam.
The Risk Identification, Monitoring, and Analysis domain defines four (4) tasks that a certified SSCP should be able to perform:
- Understand the Risk Management Process
- Perform Security Assessment Activities
- Operate and Maintain Monitoring Systems
- Analyze Monitoring Results
This is part 3 in a 7-part series on the (ISC)2 SSCP Common Body of Knowledge (CBK).
Remember: An SSCP who can recall this information will likely pass the exam, but the SSCP who can explain how these concepts are applied in real-world situations is more likely to get hired.
Understand the Risk Management Process
Risk is a tricky concept. Think of it as exposure to potential harm or loss. Risk isn’t just about the bad things that already happened. It’s also about the bad things that could happen.
Your first risk management activity should be to perform a simple risk assessment. Here’s a very simple way to do just that:
- Sit down in a room with a small group of employees from both IT and the front-line business.
- Ask them, “What are some bad things that could happen that might impact our organization?”
- Another good question is, “What things could happen here that might interrupt our ability to do what our customers expect us to do?”
- Write down the answers.
- When you get to 10-20 answers, change the conversation. For each item in the list, ask two questions:
- “How often do we think this might happen here?”
- “If this thing does happen, how much damage will it do?”
- Record your answers and thank everyone for their time.
You can use the information you just gathered to create a risk register. A risk register is a list of risks (bad things that could happen) that includes their estimated likelihood (how often…) and impact (how much damage…).
As you repeat this process, you’ll begin adding more structure to collecting and sharing this information. You’ll also incorporate risk management concepts such as:
- Threats – People or events that can harm your organization, either intentionally or unintentionally.
- Vulnerabilities – Weaknesses in your security controls that make it easier for threats to do damage.
- Likelihood – How often a bad thing could happen, formalized in some sort of scale. For example, you might score the likelihood of each risk on a scale of 1 (happens once a decade) to 5 (happens once a day).
- Impact – How you would measure the damage, formalized in some sort of scale. For example, you might score the impact of a each risk on a scale of 1 (15-minute help desk call) to 5 (business ending event).
You’ll also begin tracking what you intend to do about each risk in the risk register. Common options include:
- Accept – Decide you’re okay with the risk and take no action.
- Transfer – Make it someone else’s problem (e.g., insurance provider).
- Mitigate – Put controls in place to reduce the likelihood, impact, or both.
- Avoid – Change your business plans to negate the risk. For example, if you decide the risk of an external web application being compromised to too high, you may choose to take the application offline so that attackers can’t target it at all.
Once you start tracking these risks, you may find that some of them are never resolved. In many organizations, unresolved risks become audit findings. These risks end up in a report that goes to executive leadership and/or the board of directors. If your name comes up in either of those groups, you definitely don’t want it to be because you have an unresolved audit finding.
As you start collecting, documenting, and sharing this information, you’ll find that you’ve implemented basic risk visibility and reporting processes. You can improve these processes over time, as the organization’s understanding of risk matures. You may ultimately participate in an Information Sharing and Analysis Center (ISAC), where you can share threat intelligence, or information about bad actors that may ultimately target your information.
NIST Special Publication 800-30 (rev 1) is an incredible (free) resource to help you understand how to conduct a risk assessment.
If you’re interested in reading up on risks that resulted in data breaches, check out the Chronology of Data Breaches, as well as Verizon’s Data Breach Investigations Report (DBIR).
Perform Security Assessment Activities
With your policies and standards in place, and with your security controls up and running, how do you confirm that they’re working as intended?
That’s a simple question with a complex answer.
When you participation in security testing and evaluation, you will use a number of different technologies to confirm that your controls are effective.
One of the most common tools in this space is a vulnerability scanner. These scanners will identify live systems on a network, and then test those systems for known weaknesses (e.g., missing patches, security misconfigurations). Some of the more well-known vulnerability scanners are:
- Nexpose (from Rapid7)
- Nessus (from Tenable)
- OpenVAS (an open source solution)
- QualysGuard (from Qualys)
These solutions were designed to scan for system-level vulnerabilities. When it comes to web and mobile applications, scanning for vulnerabilities is much more complex. As a result, the security industry has developed a number of application security scanners as well. Curious about how many application security scanners are out there? Check out this list.
An SSCP will be expected to interpret and report on scanning and testing results. The scan results by themselves have little value without a qualified professional who can translate those findings into reasonable risk remediation recommendations. This includes identifying false positives (i.e., inaccurate scan results), prioritizing the detected vulnerabilities, and working with system and application administrators to determine whether or not a recommended fix can be applied in your environment. (This is where an understanding of compensating controls comes in handy.)
NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, contains considerable information on how to perform security assessment activities.
Operate and Maintain Monitoring Systems
SSCP’s need to be able to distinguish between events of interest and security incidents.
An event of interest is some activity or log entry that could be an indicator that something bad has happened (or is about to happen). Consider a failed login event. Was it an attacker attempting to guess a user’s password, or was it a user who accidentally hit the wrong key on the keyboard?
By analyzing these events, you should be able to determine whether or not an attacker was successful. Successful attacks are considered security incidents, particularly if that attack requires that you take some action to stop the attack and repair the damage.
Take social engineering, for example. If a criminal sends a phishing email to one of your users, but the user deletes the email without opening it, was that an event or an incident? That’s right. That was an event. And if the user clicked on the link in the phishing email and installed malware on his computer? Now you have an incident on your hands.
This is why logging is crucial to any successful security program. Logging is the process of recording those events for later analysis. Logs should be configured with enough detail that you can reconstruct what originally happened. Logs should also be stored in a central, secure location to ensure that they are protected from intentional tampering or accidental deletion.
Once you understand how to configure your logging controls, you need to apply that configuration to every source system that you intend to monitor. Those source systems can include endpoints (workstations), server operating systems, web servers, database servers, email servers, web applications, network devices… the list goes on and on. You’ll need to spend some time learning about the technologies deployed in your environment, and about the logging capabilities within each technology.
If you’re interested in the logged events that are most likely to be useful during security incident response, check out Lenny Zeltser’s Critical Log Review Checklist for Security Incidents.
Analyze Monitoring Metrics
Event data analysis is most effective when you compare data from from multiple systems of interest.
An attacker attempting to steal database information through an external web interface will leave tracks in multiple locations: firewall logs, web application logs, web server logs, server operating system logs, and database logs. You will also find value in collecting data from packet dumps, or raw captures of all the data that travels between systems of interest.
(For more on packet dumps, check out Wireshark.)
Over time, you’ll have enough log data and security incident information that you’ll be able to perform security analytics. By developing a baseline (or trends that paint a picture of what “normal” looks like on your network), you’ll be able to fine tune your monitoring systems to alert on fewer false positives (and to catch some activities you may have missed before).
Ultimately, you should be able to define and track metrics to help you improve over time. Common monitoring metrics include:
- Percentage of source systems sending logs to a centralized repository.
- Number of security incidents.
- Mean time to detect a security incident.
- Mean time to resolve a security incident.
Understand your target audiences for these metrics, and you’ll be able to develop an appropriate visualization for each one. People tend to think in images and pictures, and being able to represent your metrics in some sort of visual dashboard will help you quickly and efficiently communicate your findings to the teams and leaders who rely on that information.
- System and application administrators need more detailed information in order to update their environments to improve logging and monitoring controls.
- Management needs summarized information for all systems and applications that they own.
- Leadership (executives) need very high level details, particularly around coverage and around incident response capabilities.
What Else Should I Know About Risk Identification, Monitoring, and Analysis?
This is a high level introduction to the concepts you need to know as an SSCP, based on the (ISC)2 SSCP Certification Exam Outline. It’s not intended to be a deep-dive into everything you need to know in order to pass the exam.
You’ll increase your chances of passing the exam the first time if you read these two (2) books next:
- Start with the SSCP All-in-One Exam Guide (2nd Edition).
- Then read the (ISC)2 SSCP Official Study Guide.
If you prefer videos to books, use our list of recommended online training providers to take advantage of FREE offers to help you prepare for the exam.
Keep at it!
SSCP Domain 2 – Security Operations and Administration | SSCP Domain 4 – Incident Response and Recovery
