Notes from the Field - CIS Control 18 - Penetration Testing

While working with clients I will review their latest penetration test report. Penetration tests are a great way to obtain independent and unfiltered information about your organization’s vulnerabilities The tests are usually performed by an outside information security firm, giving you an outsider’s view of what’s going on at your company. That view is valuable as outsiders provide another perspective. 

The first thing I look to see is if it’s a real pen test or a typical vulnerability scan. Unfortunately,

Circles in the Sand at Bandon Beach, Oregon

clients often pay for a pen test and receive a vulnerability scan report that they could have produced themselves without having paid tens of thousands of dollars.

A true pen test report will include the scope of the test. The report lists the tools and procedures performed. The pen testers will attempt manual exploitations of vulnerabilities that were identified by scans. Tests should also include phishing and spear-phishing attempts, other social engineering, and physical penetration attempts. Unlike vulnerability scans, which may only take a few hours, pen tests may take several days or weeks, depending on the size and complexity of the organization.

In this post I discuss Center for Internet Security Control 18 - Penetration Testing. This is the 18th and final post in a series on the Center for Internet Security Controls. The document consists of 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. The document contains high level information that executives can understand and also has specific details about tools and procedures for technical staff to run with. I recommend it to all my clients for information security guidance. 

 

The Overview for Control 18 - Penetration Testing is - Test the effectiveness and resiliency of enterprise assets through identifying and exploiting weaknesses in controls (people, processes, and technology), and simulating the objectives and actions of an attacker.

Why is this Control Critical? No company is completely secure, even organizations with mature information security policies, tools, procedures, and well trained staff. Existing technologies continuously change. New technologies are released daily. Systems are very complex. New vulnerabilities are discovered every day. Attackers leverage these factors to bypass your company's security controls and trick your employees into giving up their credentials. 

It is imperative that your organization periodically undergo penetration tests by qualified independent internal or external parties. Pen tests can identify gaps in your company’s security tools, configurations or staff training. Use the identified gaps to make adjustments to your environment and provide the additional training needed to improve your organization’s security posture. 

CIS Control 18 has 5 safeguards in support of incident response. They are: 

18.1 Establish and Maintain a Penetration Testing Program - this one is pretty clear in which your organization creates its pen test program, defining the scope of testing. That can include specific networks, web applications, APIs, hosted services, social engineering, physical security. 

18.2 Perform Periodic External Penetration Tests - perform external pen tests at least annually. I recommend pen tests at least twice a year. People often say their environments are static and pen tests more than once a year are unnecessary. But are the environments truly static? Organizations install security updates monthly and deploy application code updates frequently. They also change configurations, sometimes inadvertently. Pen tests will help identify vulnerabilities not detected by regular vulnerability scans.  

18.3 Remediate Penetration Test Findings - this one is also pretty clear. Remediate the findings by updating vulnerable code, installing security patches, correcting configuration issues, better physical security controls, and providing better training for individuals who fell for social engineering efforts. Prioritize remediation according to the severity of the findings. For small environments, there may be a handful of findings that can be resolved quickly. For large environments with many applications and hundreds or thousands of systems, remediation is more involved and time consuming.  

18.4 Validate Security Measures - this involves tasks such as reviewing security controls and tools, WAF rules, and firewall rules. Determine if rules need to be more rigorous or additional tools added to protect your organization.  

18.5 Perform Periodic Internal Penetration Tests - Similar to the frequency with performing external pen tests, do the same with internal pen tests. Again, you may likely meet your security framework requirements by performing internal pen tests annually. But you want to do them at least twice a year to identify code issues, vulnerabilities, and misconfigurations. 

The CIS Control document states that internal and external pen tests should be performed by a qualified party. What is a qualified party? Do pen tests need to be performed by an external security firm? Pen tests do not need to be done by an external company. But the tests should be performed by an organizationally independent team. 

Larger organizations often have internal security internal departments with pen test teams that are independent of the departments they test. Smaller organizations may need to engage a security firm to perform the testing. In any event, the person or team performing the testing should not be the same individual or team responsible for managing the systems. The pen test reports need to be delivered to the senior manager as well as the team that manages the systems as well as to the team. It’s important for senior management to be aware of the risks to the organization identified in the report and provide appropriate oversight. I’ve seen cases where the pen tests are only delivered to the individuals that manage the systems. Management is not information about the threats the company faces. 

The CIS Controls document lists as a resource the The PCI Security Standards Council. It discusses pen test methodology, scope, reports, case studies, and discusses the qualifications for pen testers in its Penetration Test Guidance publications. The document also lists as an additional resource OSSTMM 3 - the Open Source Security Testing Methodology Manual.

Penetration testing, combined with the other CIS Controls will help your organization better protect your company and customer data.

Notes from the Field - CIS Control 17 - Incident Response Management

The client I was working with had a SaaS application hosted in AWS. When we discussed how they would respond if their data were compromised, they said that wasn’t a serious concern as the data the company collected was of little value. Nobody would want it. It didn’t have personally identifiable information (PII), such as social security numbers, license numbers or medical information. When I raised the prospect of a ransomware attack and the damage it could do to their operations and reputation, they began to realize the potential consequences of their lack of preparation. Most companies understand that they could be the target of an attack. Some don’t. But all need incident response processes in place for when an incident occurs.

Castillo San Felipe del Morro, San Juan, Puerto Rico

In this post I discuss the Center for Internet Security Control 17 - Incident Response Management. The Center for Internet Security Controls are 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. The document contains high level information that executives can understand and also has specific details about tools and procedures for technical staff to run with. I recommend it to all my clients for information security guidance. 

The Overview for Control 17 is - Establish a program to develop and maintain an incident response capability (e.g., policies, plans, procedures, defined roles, training, and communications) to prepare, detect, and quickly respond to an attack.

Why is this Control Critical? Companies often don't have incident response and recovery capabilities even when they have detection and prevention controls in place. If such a company does have a compromise or other incident, they may not have people with the appropriate skills and experience to contain the incident and keep it from spreading. Without a full understanding of such attacks, incident responders will be in a perpetual state of being a step behind attackers. Even with a good plan and people, it's important that that regular training be provided to staff that will respond to incidents. 

Control 17 has 9 safeguards in support of incident response. They are: 

17.1 Designate Personnel to Manage Incident Handling

17.2 Establish and Maintain Contact Information for Reporting Security Incidents

17.3 Establish and Maintain an Enterprise Process for Reporting Incidents

17.4 Establish and Maintain an Incident Response Process

17.5 Assign Key Role and Responsibilities 

17.6 Define Mechanisms for Communicating During Incident Response

17.7 Conduct Routine Incident Response Exercises

17.8 Conduct Post-Incident Reviews

17.9 Establish and Maintain Security Incident Thresholds

Let's take a look at a few of these starting with 17.1 Designate Personnel to Manage Incident Handling. Smaller and mid-size companies I've worked with often don't have a dedicated Security Operations Center (SOC). Incident response falls to the DevOps or IT teams. But the roles are not formally assigned. The individuals who must respond often don't know they are responsible until there is an incident. Their regular duties don't include responding to incidents. When one happens they are unprepared to take appropriate action.  

17.4 Establish and Maintain an Incident Response Process and 17.5 Assign Key Roles and Responsibilities - you can combine these two safeguards and potentially the first five safeguards. This is where you document an incident response policy and process. You identify the specific roles and responsibilities for responding to incidents. Establish processes for how individuals will report incidents and the activities to respond.    

17.7 Conduct Routine Incident Response Exercises is key for all companies, particularly those without a SOC or other personnel who routinely respond to incidents. It's important for teams to engage in monthly or quarterly training to run through attack scenarios and how they would respond. Each team member would become more and more familiar with their role in incident response processes and what action to take. While not a replacement for actual experience, the individuals involved will understand what to do rather than try to figure it out during an actual incident. 

17.8 Conduct Post-Incident Reviews is where teams use lessons learned from an incident to determine how to improve their response procedures in advance of the next incident. What could they have done differently or would the response have been better if the tasks were performed in a different order? Did any steps slow down the response process? What controls can they put in place now to prevent or mitigate this same type of attack from occurring in the future?  What tools do they need to better respond? Agree among the team on next steps going forward, such as updating the incident response checklist or playbook. 

CIS Control 17 is a good way to get started with incident response management. In the next post, I will cover the final control, Center for Internet Security Control 18 - Penetration Testing.  

Notes from the Field - CIS Control 16 - Application Software Security

Working recently with a small Software as a Services (SaaS) company, it quickly became clear they didn't have much in place by way of security. They didn't have a documented policy. They didn't do code reviews. New code releases were deployed on the fly. They didn't do secure scans of code or the web application. They didn't have a WAF. The application database was hosted on the same server as the application server. There were a handful of developers who had many years of experience. They were supposedly knowledgeable in software development best practices and didn't need what they considered rigid and unnecessary security controls.

That's when I discussed some basics around application security from CIS Control 16. The Center for Internet Security Controls are 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. The document contains high level information that executives can understand and also has specific details about tools and procedures that technical staff to run with. I recommend it to all my clients for information security guidance. 

Warning Sign at Colyer Lake in Central PA

The Overview for Control 16 - Application Software Security is - Manage the security life cycle of in-house developed, hosted, or acquired software to prevent, detect, and remediate security weaknesses before they can impact the enterprise.

Why is this control critical? Attackers can use a company's own public-facing applications to bypass network security tools to compromise company and customer data. Attackers can also use applications to steal user credentials and install malware on user systems. Today's applications are complex and are designed to be accessible from many different platforms - web browsers, mobiles apps, API calls. Development cycles are much more frequent than they used to be, as much as multiple times per day or week compared to a release once or twice a year. Additionally, developers use many open-source libraries that need to be updated. These elements make application security very challenging. That makes it imperative to implement and maintain proper security controls in support of in-house developed and off-the-shelf applications.

 Control 16 includes 14 sub-controls or safeguards. They are:

16.1 Establish and Maintain a Secure Application Development Process

16.2 Establish and Maintain a Process to Accept and Address Software Vulnerabilities
16.3 Perform Root Cause Analysis on Security Vulnerabilities Applications
16.4 Establish and Manage an Inventory of Third-Party Software Components
16.5 Use Up-to-Date and Trusted Third-Party Software Components
16.6 Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities
16.7 Use Standard Hardening Configuration Templates for Application Infrastructure
16.8 Separate Production and Non-Production Systems
16.9 Train Developers in Application Security Concepts and Secure Coding
16.10 Train Developers in Application Security Concepts and Secure Coding
16.11 Leverage Vetted Modules or Services for Application Security Components
16.12 Implement Code-Level Security Checks
16.13 Conduct Application Penetration Testing
16.14 Conduct Threat Modeling

Let's discuss some of the above controls. The very first one, Control 16.1 - Establish and Maintain a Secure Application Development Process lays the groundwork for the entire control and the safeguards that follow it. Document a policy and implement procedures at your organization that establishes development requirements - such as restricting access to code repositories; code reviews by a peer or a team lead before code advances in the code pipeline; DAST scans of code and libraries to identify vulnerabilities; SAST scans of applications. QA testing and user acceptance testing should be defined. The document should also state how new versions of code are released. It is an automated process after code has passed a series of manual and automated testing or is there a team that must sign off on release of the new version.

The security standard the company follows should also be listed, such as OWASP Top 10 with at least annual refresher training for developers on common application security concerns. 

Control 16.10 - Apply Secure Design Principles in Application Architectures is so important to get right as it's difficult to correct if you get it wrong. It's important to design your application and supporting infrastructure to minimize the attack surface. Some companies put their servers and databases directly on the internet facing the public. The companies I've worked with that do have good controls in place generally use Cloudflare's DDOS and WAF protection to filter all traffic before it reaches AWS load balancers. This protects their systems, putting web, application and other servers on private IPs, not directly accessible to the internet. The company also benefits by freeing up resources instead of implementing complex and expensive security controls that they can obtain from Cloudflare or other vendors. 

For Control 16.12 - Implement Code Level Security Checks - Companies with good development practices use code analysis tools such as BurpSuite, Brakeman, Qualysis, and SonarQube to name a few. There are many different tools for specific programming languages. Some of these can be used for DAST scanning of the actual application. In any event, it's necessary to use such tools to find vulnerabilities in your own code, the libraries your code is built upon, and at the application level. 

Control 16.13 - Conduct Application Penetration Testing - helps identify vulnerabilities in your applications that could not be identified using automated tools. If your organization does not have internal resources that can perform a pen test, engage a security firm to do so. First make sure you know in advance what you will receive from the firm as to what their pen test entails. Clients unfamiliar with pen tests have shown me reports that were basically vulnerability scans with some narrative details about the scope added. No actual manual testing by a skilled offensive security professional was performed. And they paid a lot of money for a vulnerability scan. 

Ask to see a sample report before deciding on a company. If they decline to provide one, that's a red flag and you should move on until you find a pen test firm you are confident will conduct a detailed scan. A thorough pen test will include a discussion with your team and the pen testers about your environment. The report should include actionable recommendations to better secure your application and environment. 

Implementing the guidance from CIS Control 16 will go a long way to protecting your company's in-house and third-party applications as well as your company and customer data. 

In the next post, I discuss CIS Control 17 - Incident Response Management.

Notes from the Field - CIS Control 15 - Service Provider Management

The client I was conducting a gap analysis for had an incredibly detailed Service Provider Management Policy. It required the company compliance team to conduct due diligence on all prospective service providers, including a risk analysis of each. The  policy required the compliance team to review the prospective vendor's SOC 2 audit report, research the vendor's financial stability, and reputation. The compliance team was to conduct annual reviews of each vendor that included many of the same steps. Great stuff.

Fraley's Robot Repair Shop, Pittsburgh, PA  Airport

When I asked them to provide evidence of activity in support of due diligence of their newly added service providers from the past year and evidence of the reviews of current vendors, they provided a couple of emails listing questions about the service and references to a completed demo of the services. They didn't have the completed risk analyses or any documentation that they performed reviews of the audit reports or any of the work required by their policy and by industry standards. Why? They found a template policy on the internet and used that as their own. They didn't actually do much in support of service provider management or think it was important. Like many clients, they thought having a policy was sufficient. 

I referred them to the Center for Internet Security Control 15 - Service Provider Management. The Center for Internet Security Controls are 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. The free but valuable document contains high level information that executives can understand and also has specific details about tools and procedures for technical staff to run with. I recommend it to all of my clients as a starting point for information security guidance. 

We discussed some of the activities they could do in support of Service Provider Management so they have assurance they have done their due diligence and can  be confident working with the vendor. 

The overview for Control 15 is - Develop a process to evaluate service providers who hold sensitive data, or are responsible for an enterprise’s critical IT platforms or processes, to ensure these providers are protecting those platforms and data appropriately.

There are 7 sub-controls or safeguards for Control 15. They are: 

15.1 Establish and Maintain an Inventory of Service Providers

15.2 Establish and Maintain a Service Provider Management Policy  

15.3 Classify Service Providers

15.4. Ensure Service Provider Contracts Include Security Requirements

15.5. Assess Service Providers

15.6. Monitor Service Providers

15.7 Securely Decommission Service Providers

Why is this control critical? Companies often rely on service providers for many services, such as data center providers, cloud service providers, third-parties to manage technology and security solutions. There have been many cases where service providers had been breached or experienced service outages that impacted companies. It's important that your company has practices in place to vet vendors and review them annually. 

I recommend to clients that don't have anything in place to begin with a list

Let's take a look at some of the safeguards:

15.1 - Establish and Maintain an Inventory of Service Providers is the logical place to start. Just like CIS Controls 1 and 2 for system and software inventories, it's necessary to know what you have in order to protect it. It's the same with service providers. Often the clients I work with don't have a list of them. It may be a decentralized process in which the department that needs the service is responsible for the due diligence and review activities. No one else in the company is aware the provider is used. The easiest way to start is with a spreadsheet listing each vendor and the service they provide. Include on the list what data they store, process or transmit on your company's behalf. 

15.2 Establish and Maintain a Service Provider Management Policy is pretty straight forward. For many areas of information security, a policy is required that outlines what the mandate is, such as maintaining an inventory of service providers in this case, conducting due diligence on new vendors, performing annual reviews of them. The policy will also outline the activities in support of the policy - who is responsible for the activities, annual policy reviews and so on. 

15.5. Assess Service Providers is basically conducting due diligence of service providers before engaging them for services. This entails reviewing their SOC 2 audit report or Attestation of Compliance for PCI-DSS to understand their security controls. For large companies, such as AWS and AZure, that's as much as you might be able to do as they are not going to allow your company to audit them directly. Nor would it be practical. 

For smaller companies that have not undergone SOC 2 or other audits, you can request they complete a due diligence questionnaire (DDQ) that addresses their security controls. While they answer your questions about security, they are not evidence that the controls are actually in place and operating effectively. Additionally, you may request evidence, such as completed vulnerability scans, pen tests, reports on patching of systems, and their information security policy. 

15.7 Securely Decommission Service Providers is a crucial process for protecting your company. Service Providers often store critical data, such as PII, ePHI or credit card holder data. What happens to your data after you stop using a provider? Is it stored by the service provider or securely deleted? The clients I work with that have a Software as a Service platform often store their customer data forever, unless the customer specifically requests their data to be deleted. Some don't even have methods to purge their databases of individual customers even if they request it. 

You want to make sure and see evidence that your service providers have deleted all of your sensitive data after you stop using their service. There is no good reason for them to maintain it. If the vendor is compromised years later, the attackers have access to your sensitive data when it never should have been with the former service provider in the first place. 

Additionally, you want to revoke service provider access to your network at the end of a contract. Often companies engage managed service providers with accounts on their networks to manage systems. Remember to disable and delete their accounts after you stop using their services. You don't want a rogue employee of the service provider or an automated scheduled task to impact your systems.

For more information on Service Provider Management safeguards to protect your company networks and data, see the Center for Internet Security Controls Document.  

In the next post I'll discuss Center for Internet Security Control 16 - Application Software Security. 

Notes from the Field - CIS Control 14 - Security Awareness and Skills Training

Security awareness training is one of the areas in which I see companies doing either very well or they don't do at all. It's unfortunate for the companies that don't do much as a little training goes a very long way. It's an investment that more than pays for itself. The more your employees are trained against potential threats and attacks, the safer your company and customer data. The less trained they are, the more your company is at risk to attack and compromise. In this post I discuss what I see as an information security auditor working with the clients regarding the Center for Internet Security Control 14 - Security Awareness and Skill Training. 

The Arch in Summer, the Arboretum at Penn State

The Center for Internet Security Controls are 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. The free but valuable document contains high level information that executives can understand and also has specific details about tools and procedures for technical staff to run with. I recommend it to all of my clients for information security guidance. 

The Overview for Control 14 - Security Awareness and Skills Training is - Establish and maintain a security awareness program to influence behavior among the workforce to be security conscious and properly skilled to reduce cybersecurity risks to the enterprise.

Control 14 includes 9 sub-controls or safeguards. They are: 

14.1  Establish and Maintain a Security Awareness Program

14.2  Train Workforce Members to Recognize Social Engineering Attacks

14.3  Train Workforce Members on Authentication Best Practices

14.4  Train Workforce on Data Handling Best Practices

14.5  Train Workforce Members on Causes of Unintentional Data Exposure

14.6  Train Workforce Members on Recognizing and Reporting Security Incidents

14.7  Train Workforce on How to Identify and Report if Their Enterprise Assets are Missing Security Updates

14.8  Train Workforce on Dangers of Connecting to and Transmitting Enterprise Data Over Insecure Networks  

14.9  Conduct Role-Specific Awareness and Skills Training. 

Why is this control critical? This control addresses the human security vulnerability, perhaps the biggest vulnerability of all. All of the technical, administrative, and physical controls in the world can easily be undermined if your employees allow unauthorized people into facilities, click on links in phishing emails, open malicious attachments or visit fraudulent websites and enter their company user credentials. Such actions could allow an attacker to gain a foothold in your environment to install ransomware or exfiltrate company and customer data. Security awareness training will provide protections against such threats. Let's take a look at some of the safeguards and how companies accomplish them.    

Safeguard 14.1 - Establishing and Maintaining a Security Awareness Program can be done by signing up your organization with an online training platform or using an existing service that your Human Resources Information System SaaS platform offers. As part of an employee's onboarding processes, new employees should be required to take the awareness training within their first week of employment to make sure the training is successfully completed. Additional, shorter training modules and phishing tests are recommended to be completed each month to continuously strengthen the information security awareness muscle. Annual refresher training should also be required for all employees. The paid services offer reporting to show who has successfully completed the training. Human Resources staff follow up with individuals who do not complete the training as they do with other types of required training.   

Companies such as KnowBe4 and Proofpoint, are two popular services, among the many training tools available. Some companies choose to develop their own internal information security awareness training. It's usually made up of a PowerPoint presentation put together by IT and IT security staff, who go over the materials with company employees. Both types of training cover the basics, such as sharing their account passwords, using multi-factor authentication when possible, not clicking on attachments or links from unfamiliar senders, not submitting credentials or financial information to bogus websites, not falling victim to social engineering attacks, and so on. Quizzes are often used to test the knowledge of participants. 

Safeguard 14.5 - Train Workforce Members on Causes of Unintentional Data Exposure is critical to protect company and customer data, as well as protect companies from the legal and financial liability as a result of such exposures. Well trained employees are taught not to share sensitive data with people who do not have a need or right to see it. They are also taught how to properly share information with those who do have a need or right to the data. The data leaks my clients have experienced are often due to lack of knowledge. Scenarios include an employee accidentally sending a patient or client the data of a different patient or client. For healthcare companies subject to HIPAA requirements, such a mistake can result in expensive fines. There have also been cases where companies I've worked with have processes in place to share with partners customer data after the data has been anonymized to protect the identities of customers. On occasion the automated anonymization process fails but the data is still shared as the companies don't have proper verification processes in place. There are many other methods where data is unintentionally exposed. In all cases, proper training is needed as a baseline to protect the data and the company. 

Safeguard 14.6 - Train Workforce Members on Recognizing and Reporting Security Incidents is supremely important because people who are trained properly, know what to do. They report an incident to the people who can take appropriate action and contain the incident. People who are not trained, often are afraid to report an incident as they think they may get in trouble for having done something wrong. As a result of doing nothing, a containable incident is not contained and causes a lot of damage. 

Safeguard 14.9 - Conduct Role-Specific Awareness and Skills Training is often overlooked even in companies that have basic security awareness training. It's important that software developers receive annual training on secure coding practices. This helps them to stay up to date on the latest code vulnerabilities and practices to avoid them. IT and IT security staff should also receive annual training for responding to incidents and for protecting the technologies they support. Staff in other areas, such as senior executives and finance should receive more advanced training to prevent them from succumbing to bogus text messages and phishing emails, especially those regarding wiring money to the fraudulent recipients.  

Whether you choose an online training platform or offer in-house training, your organization must provide company employees with security awareness training. It is the most effective method for protecting company and customer data. The Center for Internet Security Controls can help. 

In the next post I'll discuss, Center for Internet Security Control 15 - Service Provider Management. 

Notes from the Field - CIS Control 13 - Network Monitoring and Defense

“How would you know if your network or systems have been compromised?” That’s the question I often ask clients when discussing their networking monitoring and defense tools. An IT manager of a small company I worked with recently was honest and said he wasn’t sure. He was so busy putting out different fires every day, he didn’t know where to begin. The IT team consisted of four people. And he didn’t have much of a budget to implement expensive tools and create a Security Operations Center (SOC), like large companies have. That was a good opportunity to introduce him to the Center for Internet Security Controls, specifically Control 13 - Network Monitoring and Defense. 

The Overlook Pavillion at the Arboretum at Penn State

Many companies I audit have little to no network monitoring tools and processes in place
while others have advanced tools in place but no processes to leverage the tools. Security alerts go uninvestigated. Companies that are successful in this area have both tools to identify threats and a person or a team of people to review security alerts and investigate. 

The overview for Control 13 - Network Monitoring and Defense is - operate processes and tooling to establish and maintain comprehensive network monitoring and defense against security threats across the enterprise’s network infrastructure and user base.

Control 13 includes 11 safeguards or sub-controls:

13.1 Centralize Security Event Alerting

13.2 Deploy a Host-Based Intrusion Detection Solution

13.3 Deploy a Network Intrusion Detection Solution

13.4 Perform Traffic Filtering Between Network Segments

13.5 Manage Access Control for Remote Assets Devices

13.6 Collect Network Traffic Flow Logs

13.7 Deploy a Host-Based Intrusion Prevention Solution

13.8 Deploy a Network Intrusion Prevention Solution

13.9 Deploy Port-Level Access Control

13.10 Perform Application Layer Filtering

13.11 Tune Security Event Alerting Thresholds

Why is this control critical?  No network is 100% secure, no matter how well architectured. Even with appropriately implemented security controls, misconfigurations or lack of knowledge of security goals can cause gaps in the tools and security.

Skilled security and operations staff must monitor alerting tools and respond before threats can impact the organization. Companies of all sizes must develop incident response capability to detect, analyze, and mitigate attacks.   

When a company is compromised, they sometimes may not discover the breach for months or years. During that time, the attacker is exfiltrating company and customer data.

The CIS Control document discusses the use of weekly log reviews to tune triggers of alerting tools. The document stresses that while tools are necessary for logging and alerts, they cannot replace skilled information security staff and systems administrators that can understand and investigate the alerts.

Let’s take a look at some of these safeguards and how companies I’ve worked with have successfully implemented them. 

For safeguard 13.1 Centralize Security Event Alerting, the clients I work with often have a SIEM tool in place, such as Splunk, OSSEC, Wazuh, the ELK stack or similar tools in place. These tools collect logs from all types of systems. Security staff can configure alerts to be sent via email or text on different types of activity, such as change in account privileges, account password changes, unusual login activity, system and data access. The tools also provide reporting capabilities to identify new errors or potential threats so that organizations can take appropriate action. Some of the tools, such as OSSEC, are open-source and do not require license fees. Proprietary tools can be quite pricey. In all cases, there is a cost in terms of staffing to implement and monitor the tools. Staff must fine tune the queries and alerting to keep up with changing threats.  

Safeguards 13.2 and 13.7 - Some of the tools above, such as OSSEC, include an agent to install on systems. Among other features, the agents of the different tools provide host-based intrusion detection and prevention capabilities. The agents can prevent malware from being installed by blocking changes to sensitive files. OSSEC is an open-source product that I’ve seen used at many organizations. Endpoint Detection and Response (EDR) tools, such as SentinelOne and CrowdStrike provide similar functionality and are also widely used among my clients. 

Safeguards 13.3 and 13.8 address deploying network intrusion detection and prevention tools. Most on-premises firewalls have IDS/IPS tools that can be enabled, such as Snort or Suricata. These tools also exist for cloud environments to enhance security rather than solely relying on, for example, AWS security group rules to restrict network traffic. 

Safeguard 13.10 Perform Application Level Filtering - A web application firewall (WAF) is often used to protect web applications from SQL injection, Cross Site Scripting, and other Layer 7 attacks. Companies I’ve worked with often use Cloudflare or AWS WAF for the cloud hosted applications. ModSecurity is a popular choice for companies that don’t want to pay for premium services such as Cloudflare or AWS WAF.  

No matter the size of your organization or budget, you need to implement strong network monitoring and defense tools and procedures. Attackers look for easy targets. Don’t be one of them. Utilize the tools and procedures listed in the CIS Controls to better protect your company network and customer data. 

In the next post I’ll discuss Center for Internet Security Control 14 - Security Awareness and Skills Training. 

Notes from the Field - Center for Internet Security Control 12 - Network Infrastructure Management

A company I audited last fall had an insecure design for its Amazon Web Services architecture, which hosted a financial web application. The web servers were public facing as were its PostgreSQL servers. Prime targets for attackers. In most information security audits I perform, companies usually protect their web servers with layers of protection that include DDoS and reverse proxy services from companies like Cloudflare. AWS load balancers are also commonly used and placed in front of the web servers.The web servers and database servers are assigned private IP addresses, not directly exposed to the internet and attackers.

The Sun and the Four Seasons

The client agreed that their architecture was not ideal. They had been in a hurry a few years before to get the web application into production and they were new to AWS at the time. They figured they would fix it later. They never did. There was always some new project or priority that caused them to delay the redesign. As they say, if you don't have time to do it right, when will you have time to do it over? 

Unfortunately, this scenario is more common than you might expect. While most of the clients I work with have skilled and experienced network/cloud architects and systems administrators who have implemented secure infrastructures, too many still don't. They do what works and hope to secure it later. That will eventually catch up with them. 

In this post I discuss Center for Internet Security Critical Control 12 - Network Infrastructure Management. The Center for Internet Security Controls are 18 critical information security controls all organizations should implement and all information technology and security employees should be familiar with to protect their networks, systems, and data. 

The overview for Control 12 is - Establish, implement, and actively manage (track, report, correct) network devices, in order to prevent attackers from exploiting vulnerable network services and access points.

Control 12 includes 8 safeguards: 

12.1  Ensure Network Infrastructure is Up-to-Date
12.2  Establish and Maintain a Secure Network Architecture
12.3  Securely Manage Network Infrastructure
12.4  Establish and Maintain Architecture Diagram(s)
12.5  Centralize Network Authentication, Authorization, and Auditing (AAA)
12.6  Use of Secure Network Management and Communication Protocols
12.7  Ensure Remote Devices Utilize a VPN and are Connecting to an Enterprise’s AAA Infrastructure
12.8  Establish and Maintain Dedicated Computing Resources for All Administrative Work

Why is this control critical? Secure network infrastructure is essential in defense against attacks. Organizations must have an appropriate architecture that they can effectively secure. Understand that securing company and customer data is the highest priority for information security and technology professionals. Data breaches can cost companies tens or hundreds of millions of dollars from lost business, fines, legal settlements, and reputational damage. The 2013 Target data breach cost the retail giant at least $200 million in legal and other fees. Equifax agreed to pay $575 million as a result of its 2017 data breach. Both companies paid out more to recover from the breaches.   

Let's discuss a few of the safeguards listed above. Safeguard 12.1 overlaps with Control 07 - Vulnerability Management. It boils down to using supported network gear and services, installing the latest security patches and firmware updates. Clear enough. Still, in on-premises environments, clients often have firewalls with firmware that has not been updated in years, leaving them vulnerable to attack. As important as firewalls are, people forget to maintain them. If you rely on a firewall to protect your perimeter, properly manage the firewall.    

For Safeguard 12.2 - Establish and Maintain a Secure Network Architecture, I refer back to the example of the client about which I opened this post. How should companies design their AWS environments for their web application? Here's a good document and diagram from AWS advising how to properly architecture an environment. It includes additional services to leverage that you can optionally use, such as a WAF, Content Delivery Network (CDN), and an Elastic Load Balancers (ELB) to better protect your web, applications, and database servers or RDS instances. It does a good job of visually demonstrating the levels of protection and the different subnets companies can use for the different types of systems and services. 

Safeguard 12.4 - Establish and Maintain Architecture Diagram(s) seems to some industry professionals I've worked with to be a waste of time. They either don't have diagrams or they are outdated. A diagram is used to visually represent your network, systems, location of data and the flow of data in and out of your environment. The diagrams often list the ports that are open to which systems from the internet internally. You can look at it and generally understand what's going on. You can then compare the diagram to your actual network, inventory, and firewall and security rules to determine if they align. 

Do you know what happens when companies don't have network diagrams? There are usually some forgotten firewall or security group rules allowing traffic in where it shouldn't be permitted. Or there's a server sitting in the DMZ that shouldn't be there. But the infrastructure director didn't know about it because they were told by staff that everything was set up right. Without a diagram, they have to get under the hood themselves to check things out. And they may never do that.    

Safeguard 12.8 - Establish and Maintain Dedicated Computing Resources for All Administrative Work is one of the controls that distinguishes secure and insecure environments. If this safeguard is in place, many of the others are as well. In secure environments, companies require VPN access to their backend on-prem or cloud environment. Administrators then connect to a jump box, a server used for administrative tasks for the company infrastructure. The jump box is on a separate subnet from the production systems. From the jump box, the sys admins can SSH or RDP to the server they need to administer. In less secure environments, administrators can SSH or RDP directly from the internet to the servers they need to administer, no VPN or jump box. This is a dangerous practice as attackers can attempt to SSH and RDP to those same servers if they are not protected by VPN and jump box layers.

Periodic Firewall and Security Group Rules - Companies should conduct monthly or quarterly reviews of firewall and security group rules to verify they are appropriate. Network staff often test different services and tools before implementing them. That usually requires a change in firewall rules, such as opening a port for a new service or testing remote administration. Unfortunately, companies don't always don't disable or delete the rule after the testing is completed or when the technology is no longer used. The port that was opened for one technology is now open for a different server, leaving it vulnerable to attack. 

For more details on the safeguards to protect your network to prevent a data breach, see the Center for Internet Security Controls document. 

Next month I will discuss Center for Internet Security Control 13 - Network Monitoring and Defense.