CISOs and their network security teams are under increasing pressure to adhere to an expanding “alphabet soup” of regulatory requirements that have a direct impact on the enterprise network. On top of that, every business has its own internal policies and best practice workflows to follow. One way to reduce the compliance enforcement and audit-readiness burden is to work toward the goal of continuous compliance — attaining a state where all compliance requirements are met, and then continuously maintaining that state.
Even with the many challenges of managing today’s complex IT environment, it’s possible to achieve continuous compliance through proper organization, thorough processes and technology automation. In this slideshow, Ellen Fischl Bodner, Tufin, has identified six steps that are critical to ensuring continuous compliance.
How to Achieve Continuous Compliance
Click through for six steps that are critical to ensuring continuous compliance, as identified by Ellen Fischl Bodner, Tufin.
End-to-End Visibility
Gain end-to-end visibility into the enterprise requirements.
You can’t manage what you can’t see, and the first step to compliance is to gain visibility into the entire network. This means an accurate, real-time view across all business applications, including their connectivity and dependencies, and the security policies across vendors and platforms. Does your IT team know what’s happening across all network segments – including your on-premise, cloud and hybrid networks? Are you aware of all changes made in the entire environment? The ideal scenario would be to have all of this information in one convenient place and manage it from one console — one that is not a manual spreadsheet.
Network Topology and Zones
Build a dynamic model of your network topology and define network zones.
The next step is to render a clear visual model of the network topology — what the devices are and where they are (i.e., specific IP addresses), the options for routing traffic throughout the network, how various points are connected, and so on. This model must be dynamic because your network is in a state of constant change. For example, your model might show that the enterprise application that serves electronic payment processing is on the same network segment as another business application. This is a direct conflict with PCI DSS requirements, which mandate that applications for processing credit card payments be completely isolated from all other applications on the network.
Enterprise Security Policy
Define the enterprise security policy.
CISOs must define a single network security policy baseline that is unified across all vendors and platforms, on-premise, hybrid and in the cloud. The security policy should be based on the following:
- Compliance with industry-independent regulations and standards such as the National Institute of Standards (NIST) Cybersecurity Framework, EU Data Protection Directive, ISO27000 (also known as “ISO27K”) Information Security Management System (ISMS) requirements, Sarbanes-Oxley Act (SOX), etc.
- Compliance with industry-specific regulations such as Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule, North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP), etc.
- Internal governance requirements (e.g., whitelists and blacklists).
- General best practices that the company observes.
Security Gaps
Identify security gaps and align to the policy.
At this stage, CISOs should consider the organization’s unified security policy the “desired” state of the network, and not necessarily the “actual” state of the network. The actual state comes from the segmented network topology that was modeled in step 2. This is when it’s necessary to compare the two. Chances are, they will not be identical. Identify any security gaps that exist between the two and take measures to close those gaps. Continuing with the previous hypothetical PCI example, the “desired” state is that no other application has access to the network segment where your payment process application is stored. After comparing your model to the actual state of your network, you learn that a marketing application also resides on that portion of the network in order to have occasional access to customer data from the payment application. Not only is this a significant violation of PCI DSS, but it also puts the enterprise at risk for a costly data breach. This condition should be flagged for remediation immediately.
Change Requests
Create a well-defined process for change requests.
Many companies are adopting methodologies like DevOps, where changes to applications are pushed out very rapidly. It’s often the case where application updates require modifications to the network configuration, and these changes happen quickly to keep pace with business. When the network is “clean” (i.e., fully compliant with policy), that’s the right time to assess the change requests and control processes, as well as the impact they will have. This is also the time to recertify that the network is maintaining its state of continuous compliance. The recertification process includes evaluating change requests against the security policy to make sure the requested configuration change doesn’t cause a policy violation. Your change control process should include workflow documentation of precisely what changes are made, for what business purpose, and at whose request (also known as “full accountability”). The documentation needs to include sufficient comments so that compliance auditors can know what happened and why. This documentation is critically important if problems arise – or worse, in the event of a cyber attack –and the origins of changes need to be traced.
Audits
Be prepared for audits.
Compliance with regulations and internal policy is validated through audits, which in and of themselves can be quite a burden on the IT group. Audit readiness takes time and money to assemble the required documentation of the current state of the network, and to validate controls through physical tests and attestations. For instance, an auditor might want to examine all firewall rules and test a portion of them to ensure compliance. There can be several audits per year as an enterprise undergoes both internal scrutiny and external assessments for separate regulations, such as PCI DSS, SOX, NERC CIP and so on. What’s more, it’s becoming more common today for business partners to require a controls assessment before entering into a services contract. As a result, the audit burden can be quite onerous.
Documentation
Documentation of procedures and network security change activities is needed to support the audits. Other ways to demonstrate regulatory and internal compliance include reporting, change audits and history (audit trails), as well as recertification of rules and security policies.
A Healthy Compliance Posture
Like a binge diet that only results in short-term weight loss, it’s not unusual for an enterprise to intensively align its policies to pass a specific audit, and then go back to its normal workflow after the audit. Not only is this a resource-intensive approach, but it fails to improve security and validate the true nature of compliance. A better approach is to maintain continuous compliance with the overall security policy so that enterprise IT remains compliant and is ready any time for an audit.
