I’ve had dozens of discussions with our clients over the past decade to help them determine if they are doing a reasonable job in evaluating risk in their PCI environment (note – you can replace “PCI” with “any data/critical assets that you care about”). Over the course of participating in hundreds of PCI assessments, we have noticed that many companies’ risk assessment processes have been maturing nicely. Many moons ago, it was rather common for clients to ask, tongue in cheek, “Well, doesn’t the PCI assessment count as a formal risk assessment?” (Answer then was, tongue-in-cheek, “No… but…) The general mindset evolved over the next several years to “Well, we have our auditor come in each year to perform a SAS70 (now SSAE16) audit; surely that should count for something.” Unfortunately, while these audits are quite useful, they are more apt to let the world know the degree to which you adhere to your documented processes and focus less on risk to the enterprise. About 18 months ago, the PCI Risk Assessment SIG released some helpful guidelines pertaining to risk assessments, and I blogged about it then. While this was helpful information, it perhaps was not as prescriptive as many of us had hoped, so this blog post is to provide recommendations towards a good grass roots risk assessment with a little flair towards PCI (since the 3.0 version of the standard has specific call-outs).
A risk assessment program should have two components: ongoing business as usual risk analysis and periodic “stop and catch your breath” and determine risk to the enterprise. The following provides suggestions of things to review/assess for each of the categories.
Risk Never Sleeps
Since there are several elements of the risk landscape that morph and evolve on a very regular basis, it is diligent to address this part of your risk assessment strategy on a real-time or near real-time basis and, therefore, should be baked-in to your operational procedures. This activity can be tracked through regular change control or ticketing processes, or it may be tracked through keeping an ongoing risk register (which is reviewed on a regular basis). Elements that would fit this category:
- Change control: Change control is more than just taking a myopic view of vetting changes themselves from a risk perspective. Sometimes a change or a series of changes may have a potential perverse impact on your security posture, or sometimes a new technology or product offering may have potential impact.
- Current events/vulnerabilities: Whenever a vulnerability becomes known (i.e. BlackPOS/Target breach, Heartbleed), any diligent company must analyze the risk to the organization and determine if an action plan is needed or not.
- Alerts: Not only should you (or a managed services partner) monitor and respond to alerts, you should also analyze patterns, trends, and flows to determine if any pose a risk to the organization. Companies should also fine-tune their preventative (i.e. firewalls/IPS) to block nefarious activities and detective (IDS/SEIM) controls to alert on anomalous events.
- Incident Response lessons learned: PCI dictates that a company should refine their IR plan based on any lessons learned. The IR exercise should also review risk to the organization based on the incident or based on a “what-if” analysis spawned by the incident.
- New vendors/third parties: It is important to grow the business through engaging in new partners/vendors. Does your organization have a formal vetting process for both onboarding new partners as well as for periodically reviewing the security posture of existing partners? In addition to reviewing the partner, what data, applications, systems, etc. are you exposing to your partners? The degree to which you vet your partners will vary depending on the data to which they have access or control.
- Review of vulnerability scan or pen test results: While vulnerability management and pen tests are fairly straightforward, you can review patterns of any failures with associated root cause to determine if your organization is unduly exposed through slow patching or poor code release processes. Were there any findings that would cause you to revamp your SDLC or coding processes?
- Information obtained through forums/vendors: This is very similar to tracking “current events,” but it is very important to maintain strong relationships with your hardware and software partners so that you are made acutely aware of any issues/vulnerabilities as they are discovered. Oftentimes you can pressure your partners to make this information gathering seamless through forums, RSS feeds, and emails.
Periodic Risk Review
There are some elements of risk management that are better addressed on a periodic basis because sometimes it is more difficult to measure or analyze risk from one day to the next as changes over time often paint a more accurate picture. This review won’t happen by itself, nor should it be a “lone wolf” exercise. If you don’t already have a process, team, or working group to address this, you should seriously consider forming one. Even if you elect to bring in a third party to deliver the risk assessment, you will get bang for your buck by having a team in place to focus on this:
- FIM (specific PCI 3.0 call-out): The 3.0 version of the PCI DSS specifically calls out that companies should review what files their FIM solution monitors as they change over time. For example, one of our merchant clients realized that they needed to fine-tune which critical files on their POS systems were monitored.
- Monitoring/logging (specific PCI 3.0 call-out): While the PCI DSS specifies that all in scope entities should be logged and monitored, there is now a specific call-out to “10.6.2.a - Examine security policies and procedures to verify that procedures are defined for reviewing logs of all other system components periodically—either manually or via log tools—based on the organization’s policies and risk management strategy.” This means that you should review out-of-scope entities to determine that you would not require log information from them in the event a forensic analysis must be performed.
- Industry trends: Basically, you don’t want to be the “last kid on the block” to implement a security technology after everyone else has done it. This requires keeping current through reading, working with your vendors, working with industry experts, and participating in forums.
- BUSINESS risk – not just IT, including legal and regulatory: Yes, PCI standard is concerned with “just” cardholder data. What OTHER data do you need to protect, and what are you doing to protect it? Are there changes on the legal or regulatory landscape? Have you performed a risk assessment on your supply chain? What are your single points of failure? This is an element where you should be able to get great participation and buy-in from the rest of the business.
- Review of system builds: Your system build process, while it shouldn’t have to change much from year to year, should periodically be re-visited. Oftentimes it’s helpful to get a fresh set of eyes on the builds. In addition, information gleaned from vulnerability scans (are there any patterns of weaknesses or shortcomings) can also be used to refine the system build process.
- Pen testing scope: PCI 3.0 requirement 11.3 specifically calls out what portion of your environment should go through a penetration test. Organizations should work to document this scope as it A) will make it easier to demonstrate to their assessor that the pen testing was reasonably and accurately scoped, and B) allows for more accurate scoping of the pen test itself.
- Look for weak links with people, processes/groups: In the hundreds of PCI assessments and risk assessments that we’ve performed over the years, it is extremely rare for a company to maintain a 100% compliance level from one year to the next. There are always things that slip through the cracks (will write more about this in a future blog post!). Oftentimes these gaps occur through process breakdown or through changes in personnel, etc. In addition to any “lessons learned” from a PCI/risk assessment, you should review your own processes for effectiveness and sustainability.
Performing the risk analysis is the first step here. You should also have a methodology in place to determine how to address any risks that are vetted. Generally speaking, your options would be:
- Accept risk: Basically, the business is better served by not addressing the risk because the cost of addressing the risk more than outweighs with risk itself. There is nothing inherently “wrong” with accepting risk, but a diligent company ought to document the thought process associated by accepting the risk.
- Address risk head-on: ‘Nuff said.
- Transfer risk: This can be done any number of ways. For example, you may elect to bring in a third party to provide a service where you have a shortcoming (i.e. bringing in an MSSP to provide security monitoring) or you may elect to transfer risk almost all together (i.e. using a third party to provide end-to-end encryption).
- Implement compensating or mitigating controls: Oftentimes it makes sense to take a look at the “big picture” to determine if there are factors to be considered or controls to be implemented that will inherently reduce risk to an acceptable level.
For those of you who have a mature and well-defined risk assessment methodology, this blog post may provide an idea or two about refining it as risk assessments, by their own mere nature, are constantly evolving. For those of you who conduct your risk assessment on a cocktail napkin, it’s high time to strongly consider implementing a risk assessment program that allows for you to demonstrate that you HAVE given reasonable thought to your security posture, risks, vulnerabilities, and exposure – not just to your PCI environment, but ideally to any of your ecosystems where you have ANY digital assets that you care about.