Threats and Vulnerabilities

 How threatening is a threat and how vulnerable is a vulnerability?


This is a question that continues to start long discussions. 


There is no magic way to determine how threatening a threat is because the answer is always - it depends. The threat of a data breach is very concerning for some companies and for other companies, it is not very concerning. There are so many other things that come into play when you think of a threat. The threat is something that changes with the dependencies. If you drive to work, what are the threats? Other drivers are one of the very highest threats because there are so many unknowns.


Take that same scenario with vulnerabilities - the condition of your car, the condition of other cars. Some of these vulnerabilities you have control over and others you do not. You can keep your car maintenance current and not know about an issue that the manufacturer has not released a fix for and has not notified consumers. 


You start thinking about threats and vulnerabilities and the more that gets added to the list. When there is a list, it is possible that you can rank the threats and vulnerabilities from highest to lowest except that is a list that is based on your opinion. The same list could look very different to 10 different people. The list could change from day to day or season to season. Many different dependencies and variables come into play.


So, how do you quantify this data in order to understand how to secure against it? Data. 


You need sufficient data to create baselines and an understanding of the landscape that you are dealing with in determining the actual value. Take the value of the data and you may have to average the overall impact over a given period of time. Think about driving and the different seasons. The value would need to be one number which most likely would be the average for the year.


The importance of having a baseline is key to understanding how much impact it has on an environment. The baseline needs to have logic and data to back the process. This is what is key when assigning values. The process has to be repeatable and understandable. 


If I tell you that it is more risky to drive in September than January, I need to have evidence because the initial reaction would be that January often has snow and ice on the roads in colder climates. However, September is the month that school is back in session with more traffic in concentrated time along with buses that pick up children along frequently traveled roads. Having the supporting data is key to having an understanding of the threats and risk levels. 


Once the baseline is set, it is an exercise in math to determine if a threat is at a moderate level and a vulnerability at a low level the overall risk would be moderate-low or if a numerical value might be moderate is 2 and low is 1 for an overall score of 1.5. 


An organization needs to determine its risk appetite to determine at what level that additional controls or measures need to be implemented. One Organization may decide 1.7 and below they will accept the risk while another organization may decide 2 is the level of their risk appetite. 


There is not an easy answer and many books and articles have been written on the topic, the overall theme is to have a scale that makes sense and is repeatable. 

Comments

Post a Comment

Popular posts from this blog

Understanding Protection (SC)

Understanding Protection (SC) These controls focus on protecting system boundaries, communications, and preventing unauthorized data exposure. Let's break down the key SC controls with examples. SC-1: Policy and Procedures This foundational control requires documented policies and procedures for system and communications protection. Example: SYSTEM AND COMMUNICATIONS PROTECTION POLICY Version: 2.1 Last Updated: 2025-01-02 1. PURPOSE This policy establishes requirements for protecting the organization’s cloud infrastructure and communications. 2. SCOPE Applies to all cloud systems within the authorization boundary. 3. POLICIES 3.1 Encryption Requirements - All data in transit must use TLS 1.2 or higher - All data at rest must use FIPS 140-2 validated encryption - Key rotation required every 365 days 3.2 Network Security - All external connections must traverse a DMZ - Firewall rules follow deny-by-default principle - Monthly review of access control lists 4. PROCEDURES 4.1 Firewall ...
Read more

Security Assessment (SA) Controls

The Security Assessment (SA) family of controls, derived from NIST 800-53 Revision 5, plays a pivotal role in keeping systems secure over time. What Are the Security Assessment (SA) Controls? The SA family of controls focuses on ensuring that security controls are assessed for their effectiveness and are continuously monitored throughout the life of the system. This means checking whether the security measures in place are not only effective but remain effective and up-to-date as time progresses. For FedRAMP Moderate, these controls are crucial because: They ensure security controls are evaluated regularly. They support continuous monitoring for vulnerabilities or weaknesses. They establish corrective actions when necessary. SA-1: Security Assessment and Authorization Policies and Procedures Control Overview SA-1 requires the development of security assessment and authorization (A&A) policies and procedures. These procedures outline the process for conducting security assessm...
Read more

FedRAMP Moderate Rev 5 SI Controls

  In this post, I'll break down each SI control in FedRAMP Moderate Rev 5 and provide tips.   SI-1: System and Information Integrity Policy and Procedures The key to a strong base is well-documented policies and procedures.  For SI-1, organizations must: - Develop and maintain system and information integrity policies that address purpose, scope, roles, and responsibilities - Define procedures for implementing security controls - Review and update these documents at least annually Example:  Create a System and Information Integrity Policy document that includes: - Malware protection requirements with procedures - System monitoring procedures - Software and firmware update processes - Security alert handling processes and procedures - Error handling protocols  SI-2: Flaw Remediation Flaw remediation is key for maintaining system security.  Organizations must: - Identify, report, and correct system flaws promptly - Test software updates before deployment...
Read more