Introduction

Networks are noisy. From heartbeats to probing, from legitimate database extracts to covert data exfiltration, from sensor telemetry to malware infusions, there is an enormous amount of traffic on your network. Without a strategic and diligent approach, It is difficult to know how much of your traffic is appropriate. Long gone are the days when volume alone was the biggest hint that you were under attack.

Bill starts the discussion by reminding us just how much the network and the devices on the network have changed. In the last decade, we have seen not just an explosion in data volume, but a significant change in control as to how the network and the applications and devices on it are acquired, deployed and exploited for business utility. Bill also highlights the need to look at a wide range of activities to successfully monitor the organization’s infrastructure.

Matt reminds us that monitoring involves more than just checking the flashing lights for activity and sniffing packets. His advice for program monitoring shows us the broad range of health indicators that the CISO must be concerned with and how important it is to be integrated with the lines of business to know what matters to the entire organization.

Gary emphasizes the need for continued diligence through scanning, monitoring, and remediation before addressing the critical requirement for having a deep understanding of the health and security of your applications. To end this chapter, he brings the discussion back to one of our favorite topics: metrics.

Some of the questions the authors used to frame their thoughts for this chapter include:

♦  As a CISO, what frameworks, security controls, or processes would you recommend to continuously monitor your organization to prevent or mitigate a data breach?

♦  What framework and/or processes should a CISO use to remediate vulnerabilities and search for malware in their organization’s application portfolio?

♦  Your organization experiences numerous unauthorized attempts to breach its enterprise networks. What metrics are important to your enterprise cybersecurity program to enable it to see these attempts?

Monitoring the Enterprise and Your Cybersecurity Program – Hayslip

It’s 2:00 AM and the smartphone on a nightstand is chirping a lonely message for Alice Bentlee (fictitious). Alice is the Vice President, Cybersecurity and Risk Operations Director for a local bio-technical research facility and right now she is trying to brush the sleep from her eyes as she reaches for her phone. In the next fifteen minutes, she will become wide awake as she learns the news. The organization, which is her employer, has had a data breach and has activated the incident response plan. In the days to come as she triages the breach, she will use forensics to understand how it happened and what data was accessed.

The company will leverage its cyber insurance policy to help cover its costs as it initiates an internal investigation into Alice’s cybersecurity program, and as the CISO she will need to answer questions to prove her program was meeting the definition of “reasonable care.” Did she, as the senior security executive for the company, implement a cybersecurity program to the best of her ability that met industry best practices and as an organization met the standards of care for protecting the critical intellectual property data her company had stored within its enterprise networks

As a CISO, it is essential to understand the idea of “reasonable care” and why it is a minimum strategic standard for the business. This concept is based on several core principles:

  1. The organization, or the CISO acting on its behalf, shall be considered to have complied with reasonable security practices and procedures if an industry standard framework was used to implement the procedures (i.e., NIST, ISO, COBIT, and CIS), and there is a current documented information security program. This program should have mature information security policies that contain managerial, technical, operational, and physical security control measures that are at a maturity levelcommensurate with the level of sensitive information being protected by the company.
  2. In the event of legal action or a request from regulators stemming from a data breach, the organization, or the CISO acting on its behalf, may be required to demonstrate that security control measures were implemented, and they are documented in the organization’s information security policies.
  3. The security procedures are certified or audited on a regular basis by an independent auditor. The audit of reasonable security practices and procedures must be current and therefore conducted within the last year.

I am sure by now you are wondering why this is so important. The reason is that, as we’ve previously discussed, cybersecurity is a continuous lifecycle and breaches are part of that lifecycle. To reduce the risk to our organizations, as CISOs we create and implement enterprise cybersecurity programs and deploy policies, procedures, security controls, and standards to reduce risk and protect our assets. However, even with a mature cybersecurity program, we will at times remediate security breaches and then be required to prove that we are meeting reasonable security standards.

Continuous Scanning, Monitoring, and Remediation

We’re now ready for our next discussion topics. One of the primary processes that your cybersecurity program will be responsible for is “continuous monitoring.” In many network/organizational environments, there may be extreme technology change as organizations try innovative solutions to compete in their specific business markets. This dynamic change environment makes providing enterprise risk management and cybersecurity as a service extremely challenging.

To bring balance to my security teams and be effective as a security leader, when operating in chaotic business environments where there is no stable risk baseline, I implement the concept of continuous scanning, monitoring, and remediation to provide an effective security practice for my business and our stakeholders. Understanding the answers to the questions for this chapter will enable you as a CISO to state that you are meeting the requirements of “reasonable care.”

Continuous monitoring provides a critical service to security operations teams through detection, response, and remediation. When such a program is aligned with the organization’s enterprise security program and implemented with appropriate security controls, it enables security organizations to detect security incidents, remediate security gaps, and analyze trends to reduce the company’s risk exposure. I believe it is essential to understand that continuous monitoring is a component of a lifecycle, a cybersecurity lifecycle.

I have written about this lifecycle and its five stages: inventory, assessment, scanning, remediation, and monitoring (Hayslip, Pulse, Articles by Gary Hayslip 2015). This graphic is a depiction of the final stage, continuous monitoring, and will be our guide in the discussions that follow.

Figure 12.1 Continuous Monitoring Mind Map

The first question that we will review will provide some insight into the components that make up continuous monitoring and why I believe it is an essential business process. Numerous strategic frameworks address continuous monitoring. I have implemented the National Institute of Science and Technology (NIST) guidelines, NIST SP800-137 (NIST 2011) at multiple organizations over the last several years. I consider it to be a best practice for a CISO standing up a security program.

I believe it is a critical business process for organizations to understand and maintain their situational awareness and oversee their enterprise risk management portfolio. While I used the NIST guidelines for continuous monitoring, the framework you select should be decided through input from your stakeholders, including legal staff and executive management, and depends on your technical requirements.

With that said, let’s review our first question: “As a CISO, what frameworks, security controls, or processes would you recommend to continuously monitor your organization to prevent or mitigate a data breach?”

To design and implement an effective continuous monitoring program, a CISO will need to take into account answers to the following questions:

♦  Purpose of the monitoring system – From the viewpoint of the organization, what are the overall business reasons to develop a monitoring system? Is it a compliance/regulation requirement? Are there technical requirements? As a CISO you must be able to answer the question of why resources need to be expended to develop this program.

♦  Requirements – Now that you understand why you need to implement it, what are the technical, security, legal, business, and compliancerequirements for the program’s creation, management, report structure, and data views?

♦  What needs to be monitored – This question is critical. It is imperative for the CISO to work with stakeholders and trusted partners to identify what systems, applications, and data to monitor.

♦  How will it be implemented – From a technology perspective, will this monitoring be on-premises, will it be in the cloud, or would it be better to use a hybrid approach? If deploying sensors or agents, determine if the deployment is a one-to-many configuration or a distributed site-to-site configuration. Once you have identified the data to pull, you can create the architecture to move the data to a location for analysis and storage.

♦  Data, data, and more data – You have identified what data you will monitor, and now you need to ask yourself, where will the data be stored? Do I have a data retention policy? Do I have a data governance program that specifies who is allowed to access it and why?

♦  Metrics and reports – Collecting information from the monitoring program should have a purpose. Do you have any metrics? Do you have specific reports based on the analyzed data? What is the story, and to which audience are you providing this data?

♦  911 – You understand your requirements, you have built a continuous monitoring program for the organization, you are collecting information, and now the question is who will use it to protect the organization?

As you can see from these questions, there is an extensive amount of information you need to collect before you begin architecting a monitoring program. I typically start with conducting an inventory of my security suite to identify all of my security assets such as firewalls, IPS sensors, honey pots/nets, endpoint platforms, and vulnerability scanners. I then proceed to document what logs I can collect from these platforms and meet with my peers in our data centers, desktop support, and network services teams to verify what assets they have and what logs I can collect from them. Once I have identified these assets and log types, I research and deploy a security information and event management (SIEM) platform that enables me to build dashboards to analyze the collected information. This allows me to make decisions about reducing risk and focus on how to best use my limited resources.

You will need to review several issues if you plan to use a SIEM platform as one of the core elements of your continuous monitoring program. The SIEM platform will provide your monitoring program with extensive capabilities for reviewing and analyzing collected data for actionable threat mitigation. However, you will need to verify some information before you start analyzing the collected data. Some of the issues I would recommend you check are:

♦  Deployment of Security Suite Assets – Review where you have your security assets deployed in your enterprise network. Assets such as intrusion prevention systems (IPS) or unified threat management (UTM) appliances become primary sources for data logs and it is critical to position them at locations in the network with the best visibility into data flows to ensure you are collecting optimum data. Whether it’s at the network edge, chokepoints between sites, or within enclaves that manage sensitivedata – review your network maps and the position of your security suite’s

♦  Log Filtering – Next, I would recommend that, depending on the data type you collect (for instance, if the data is from security components like firewalls or IPS systems), you incorporate filters or pre-defined rulesets to remove basic informational data so your analysts don’t get overwhelmed. There are configurations for many of your security components that will allow you to filter out informational data and only send alerts for data that meet specific criteria for review by one of your security personnel. The use of these filters and automation for specific analysis will help provide relevant data and meaningful metrics for review. As a result, security staff will be able to spend less time analyzing the data and more time remediating any issues they find.

♦  Log Management – You are collecting logs and sending them to a central repository for your SIEMto review, however, what events are you collecting? Some events that I have collected in the past (and by no means is this a complete list) are:

◊  Asset boot/shutdown

◊  System process initiation/termination

◊  Invalid Login attempts

◊  File Access/File Close

◊  Invalid File Access attempts

◊  Network activity

♦  Ports/Protocols

♦  Flagged application activity (Tor, Web Proxy, File Sharing)

◊  Resource Utilization information

♦  Log Retention/Access – It is critical that you understand your log retention requirements. If you must keep logs for several years due to federal regulations or industry compliance, you will need to factor storage and encryption of the data at rest as part of your program for managing this data. Another critical question you will need to address is who needs access to these logs, why do they need access, and what rights do they need to this data? You will need to incorporate an access control mechanism for this information, so you can demonstrate you’re a good steward of the data entrusted to your program. I have found that discussing this issue with my stakeholders will help identify who needs access and the business requirements for the information, so collaborate when setting your access control mechanisms. 

Gary Hayslip