Proposal: Revisions for CIS Controls #1 and #2
ACM.178 Will lack of inventory or known vulnerabilities be more likely to facilitate a data breach?
Part of my series on Automating Cybersecurity Metrics. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
Let’s say your company had a data breach. It was a huge breach and it was all over the news like the Equifax breach, for example.
During the analysis of the breach by the news media and others it came to light that you had a known vulnerability on a public-facing, Internet-accessible web server for 5 months.
Your response to the media and everyone else who is asking is that, “Well, we were focusing on CIS #1 at the time which is identification of all our enterprise assets and then we were going to fix our known vulnerabilities later.”
How do you think that might go over?
What are the CIS Controls?
For those who are not aware, the CIS Controls are maintained by the Center for Internet Security as a baseline list of controls you can use to implement a cybersecurity program. These control aim to prioritize your activities by what will most help you stop a data breach. These controls have a fairly long history in cybersecurity and have undergone may revisions. You can find the latest version here:
The Australian government maintains a similar list called the Essential Eight here:
How to prioritize your cybersecurity efforts
Does it make sense to start with known vulnerabilities or inventory? Of course we want to do both and both are critical, but when providing organizations who are just starting out on their security journey, where should they really start? What should be the top priority?
Now let’s think about enterprise assets and data classification, for example. How are you going to identify all your assets if your assets keep changing? A large organization may be deploying more and more organizations all the time. How are you going to keep up with the rate of change in a fast moving organization?
Maybe we can reword or rethink our objectives a bit to make them more effective. We essentially have the same goals as the existing CIS controls, but maybe we can change the priorities and the way in which we approach the problems to hopefully be more effective at preventing data breaches.
What am I basing my proposal on? Over twenty five years of involvement in software and infrastructure deployments and data breach analysis. I know others have more experience in one of the other fields or both. But bringing the two together gives me a certain viewpoint.
I started out my formalized research in security by exploring the Target breach and setting out on a quest to find out: “What causes breaches?” Breaches includes not only data breaches but breaches of systems that allow any sort of unauthorized and unwanted actions. Isn’t this really our top priority in security? We want to stop breaches. Whatever is most likely to cause a data breach should be our top priority, right?
My software background gives me some insight into how automation can create repeatable processes and help prevent mistakes and subversion. Software can also help humans get things done faster, but needs human review to make sure the automation is working properly and as intended. If we want to achieve a certain objective in security, automation and software may be useful in helping us do that more effectively.
We’ve always done it that way
What? Change the number one CIS control? How long has the number one CIS control been focused on inventory? I’m not sure. The references on the Wikipedia page don’t work and I don’t really care as much about the past as I do about the future.
In the words of Grace Hopper on Data Processing in Computerworld, January 26, 1976:
…the most dangerous phrase a [computer or security professional] can use is “We’ve always done it that way.”
She’s referring to data processing here which back at that time was akin to the computing and related security activities we perform today. If you don’t know who Grace Hopper was, she identified the first computer bug — literally, a bug. She also was a pioneer in computing with many achievements.
Here’s the actual quote which includes looking to the future or possible enemy attacks:
Looking ahead means constantly reviewing what causes data breaches as attacks change over time and figuring out how we can prevent them or limit the impact and identify them faster if and when they occur.
#1 Fix kown vulnerabilities!
Since known vulnerabilities are one of the primary ways attackers obtain access to systems, shouldn’t the number one top priority of your security organization to identify assets, or to fix known vulnerabilities? Included in vulnerabilities are misconfigurations that could lead to a security breach.
Get that scan running — however you do it — and start scanning for known vulnerabilities. Scan your networks, your systems, your software, your cloud, and whatever else you need to scan to find the latest vulnerabilities that are under attack. Of course, you need to validate that your scans are working and manually test for things a scan cannot address by way of a penetration test or human analysis. Review your manual processes for potential vulnerabilities as well.
Addressing known vulnerabilities should be any organization’s top priority, in my opinion.
Phishing and credential compromise is probably the number one cause of data breaches but that is a very hard problem to solve. Even when credential compromise and phishing are the root cause of a breach it is often facilitated with a vulnerability, as was the case in the recent LastPass breach. A developer was running some out of data software on a laptop.
That’s what I think CIS #1 should be and I’ve been speaking about that for some time and wrote about it in my book at the bottom of this post. Lack of knowledge of your inventory does not cause a breach. Vulnerabilities cause breaches.
By the way:
- A security or vulnerability assessment, penetration test, or bug bounty might help you find assets you did not know existed depending on how you approach it.
- If you operate in a cloud environment like AWS, Azure, or GCP, you already have an asset inventory of compute resources by virtue of how the cloud works — as long as you have correctly set up permissions for your security personnel to access all the resources in your cloud accounts.
- If you use a solid network architecture this can effectively mitigate some vulnerabilities to a degree without patching. More on that in my book at the bottom of this post.
- A well-design security architecture can help limit the damage and facilitate identifying a breach more quickly.
- I would consider lack of phishing-resistant hardware MFA to be a vulnerability at this point — at least for administrators and those with access to sensitive data.
CIS #2 Architect and build a secure deployment system that tracks and verifies assets
CIS #1 — an inventory of all your assets (hardware) and CIS #2 — a software inventory are both important for your overall security. There’s no doubt about it and I am not in any way suggesting that inventory of your assets is unimportant. If you are not aware of an asset in your organization you cannot know it has a vulnerability or poses a risk.
However, perhaps we can word this requirement in a way that immediately improves the effectiveness of the approach to this problem, and the security outcome.
What about renaming the controls as follows to focus on the deployment process as a means for obtaining said inventory:
#1 > #2 Architect and implement a deployment process that ensures all infrastructure in your environment to exist in your inventory, with integrity checking and appropriate identification of the business need, owner, and users.
#2 > #3 Architect and implement a software deployment process that ensures that all software exists in your software inventory, with integrity checking and appropriate identification of the business need, owner, and users.
But really, we could combine #1 and #2 and add data tracking to that as well.
CIS #2 Architect and Implement a Secure Deployment Process For ALL Digital and Hardware Assets that includes integrity checking and identification of the business need, owner, data classification, and users.
It is going to be difficult to classify all your systems and assets and complete your inventory in a short period of time. A security team alone cannot perform this task as they likely don’t have insight into the inner workings of all systems and the data they contain.
What if you architect a secure deployment process that captures this information, otherwise the system may not be deployed? Now the finance department, business owners, developers, and quality assurance teams help create that inventory. Any time a system changes in your organization, your inventory is updated with the appropriate information. As changes occur, your inventory becomes more accurate with the help of everyone involved.
I got this idea from a NIST document I read related to encryption standards. It stated that any time a document was unencrypted, it had to be re-encrypted with the appropriate updated standard encryption algorithm. It would be a massive undertaking to re-encrypt every document with an updated encryption algorithm, but focusing on the documents people were actively using was a great way to start the process.
A secure deployment process will also help you with another requirement for some organizations: Track your software bill of materials (SBOM). If you use the proper tools in your deployment process this becomes easier. You won’t need to pay for external tools immediately to hunt for your inventory (though they can help and augment your processes long term).
In addition to what is currently changing, security teams can focus systems hosting sensitive and critical data if they are not changing. Teams can enlist the help of business owners across the company to identify data impacted by any kind of compliance regulation. The data owners should be responsible for identifying that data and should face consequences as deemed appropriate by the organization for failure to do so.
Once you have this deployment system in place, you might enforce a policy to redeploy each system (that you can) and go through the process of identifying all the hardware, software, and data that system encompasses and update your inventory in the process. Creating projects and tasks within the existing workflow for teams responsible for those systems with executive support will ensure the resources and budget exists to complete this initiative.
Finding your digital skeletons
One way to ensure you have not missed anything would be by migrating everything to a new network or a new cloud account. Anything that is left in the old network or account is something unidentified you need to track down.
And by the way, in the process you can enforce automation and test disaster recovery and failover at the same time.
Impossible? Here are three scenarios for you to consider:
- A company at which I worked with billions of dollars of assets under management that performed a physical data center failover about every 6 months.
- I architected a new system on AWS for a company moving a firewall product to the cloud (which was changed after my initial architecture so I don’t know how it works now). The first thing I had my team do was to build out failover for the base infrastructure. They did it in three months and demonstrated it to management at the end of a development cycle in a meeting.
- While developing our approach to deploy systems in cloud environments, Capital One moved currently deployed systems to new accounts a couple of times.
I’m not saying these things are easy. But they are possible. The question is, how much do you value disaster recovery in the event of a ransomware attack or something similar? How badly do you want to know what is in your inventory and what skeletons may be lurking in your digital closet?
Scanning for unidentified assets
I would move implementation of scanning to identify unidentified assets into a threat hunting category. This is like seeking the needle-in-the-haystack threats in your logs and should be considered a more advanced capability rather than a baseline security control for beginners.
You can spend a lot of time looking through logs and running scanning tools and while you’re doing that more and more assets are being deployed. You’ll always be playing catch up. It seems more logical to me to focus on the inputs rather than the outputs in the initial stages, other than what can be blatantly identified during a security assessment.
I was just talking to a customer who wondered why they need to buy a tool to track inventory when they have a solid and robust architecture for deployments. They don’t, in my opinion. They have the inventory by virtue of controlling the deployment process and tracking what is deployed in each deployment.
Digging through logs to find any assets that got missed might be helpful, but their network blocks any rogue deployments from reaching the Internet. It should be eas(ier) to spot a rogue piece of software in that case reaching out to the Internet based on an internal IP address trying to get to the Internet and getting blocked. So part of a solid deployment system might include a robust and segregated network architecture to help identify rogue assets. Then set up logging and alerts for the anomalous behavior I just mentioned.
Once you have all that, if you have the time, and if you have no known vulnerabilities to deal with at the moment, then go ahead and start digging through the logs — DNS requests, network traffic, invoices and expense reports for unknown software and systems, scanning source control, and so on. And perhaps you have multiple teams working on these different aspects of cybersecurity simultaneously.
What about phishing and credentials?
Stolen and abused credentials are part of almost every data breach. Phishing is definitely a problem along with vishing (tricking someone via a voicemail) and smishing (tricking someone to click a link via a text message). I’m getting bombarded with text messages telling me there’s a problem with my Amazon account right now. I confirmed that others are as well.
One of the keys here is training, but training alone is not good enough. Awareness only goes so far. In a moment of tiredness or distractedness, a phishing attack could affect any of us. In addition, the recent drive-by ads in Google that have been infecting devices is another example of how the credentials of an innocent bystander may be compromised.
The way to solve this problem is less about stopping the credential compromise, in my opinion — but what happens after that. Systems need to be architected in a way that prevents those credentials from inflicting excessive damage. And that really comes down to your security architecture, a topic of my recent blog series. Perhaps security architecture that incorporates segregation of duties, multiple people to perform sensitive actions, and least privilege should be high up on the list as well.
I presented all these concepts in my book written in 2020 which you can find at the bottom of this post.
If you want to understand some of the threats and mitigations in this space, check out my latest series where I’m implementing security on AWS from the ground up. But the principles really apply to any environment.
Here’s some additional information on cloud security architecture specifically:
Your security architecture can enforce governace. Here are some posts on that topic.
These thoughts were inspired by a recent conversation with a client on an IANS Research call. You can contact IANS to schedule a call with me. You can also contact them if you want me to perform a cloud security assessment if you are an IANS client or contact me directly on LinkedIn if you are not. I perform penetration tests and assessments but there is some overlap in the services I provide for both. I try to provide as much coverage as possible and identify (in all cases) and verify (in the case of a penetration test) as many vulnerabilities as possible — both in the software and systems but also in the architecture design, when possible.
I’ll get back to the regular blog series tomorrow where I’m trying to demonstrate and provide the code for these and other concepts I’ve been writing and talking about for a while now.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
