Prove It or Lose It
Pop quiz: what are security controls? Are they ethereal, like policies, standards, or procedures, or are they physical things like firewalls and WAFs? The answer is all of the above. A security control is something you do or use that is intended to make you or your data more secure. That includes policies, training materials, and all other tools and solutions employed.
So obviously we need controls, and we have often put in considerable effort to get them, but what about needing to prove how well the controls are performing? Being able to prove the efficacy of security controls is just as important as actually implementing them.
Far too often we get caught up in the enactment of security controls and stop there. We write policies, procedures, standards, and guidelines until we are blue in the face. We deploy tools and solutions and the new thing being touted as the next hottest security product ever. But what is being done to prove the effectiveness of those controls? Are people reading and following all those policies? Is that expensive solution being used properly? Are you getting your money’s worth out of it? This is where control validation comes in. It is used to report back to the organization the status and effectiveness of security controls.
“Do we create backups?”
“Yes.”
“Do we test our backup recovery capabilities?”
“Yes, and here is a short report or screenshot showing that we did a test a week ago and that we were able to successfully spin up a backup in our test environment.”
Another way to think of it is akin to the tree falling in the woods: if a control fails but there isn’t any proof of the control, did the control ever really exist in the first place?
Security control validation is necessary to support audits, both internal and external. If your company is going through a SOC 2 audit and you cannot prove to the auditor that a control exists or is effective, then to them you do not really have it. Aside from helping you to pass your SOC 2 or ISO 27001 audit, control validation is essential to having peace of mind that your “i”s are dotted and “t”s are crossed, and proving to senior management that the security controls are working as intended. Control validation is also critical in supporting the information security department budget.
So how does one go about validating controls? There are a multitude of ways this can be done. Let’s examine a few from each of the primary functions of the NIST cybersecurity framework (CSF). The NIST CSF is broken into five functions: Identify, Protect, Detect, Respond, and Recover.
Identify
From the Identify function, let us first examine asset management. Is there an asset management tool? If so, a screenshot of its dashboard is wonderful proof of the control. Does the tool track both software and hardware assets? If so, show that, again, with a screenshot. Is the asset registry automatically or manually updated? If it is being manually updated, then there should be logs or reports proving that whoever is responsible for the updates is performing them.
Another vital control from the Identify Function are risk assessments. If risk assessments are done in a spreadsheet, the document itself should suffice as adequate proof of the control. Risk assessments, however, should be done periodically and there should be multiple sequential copies of the risk assessments that show who performed them and when. Are the identified risks being properly handled and treated? The output of risk assessments should flow into a risk treatment plan or an information security Plan of Action and Milestones (POAM). All of these things lead into each other and serve to validate the controls.
Protect
One of the categories in the Protect function is Access Control. Everyone loves passwords and password management. Can you show what your password management methodology is? Are the requirements being enforced through something like Active Directory? If so, take a screenshot(s) that shows items like minimum and maximum password length requirements. Take screenshots of the failed login attempt threshold.
Training is also addressed in the Protect function. Don’t just include the training materials in your artifacts and evidence; take attendance to show that your employees are attending, and participating in attendance. Show that staff who miss a training are followed up with to ensure that they make up what they have missed.
Detect
The Detect function covers things like auditing, logging, and continuous monitoring. Is there a Security Information and Event Monitoring (SIEM) system? If yes, then take a snapshot of the dashboard. If no, then what are you doing about audit logs? How are they reviewed, and when? Make sure there is some sort of output from that activity. Are firewalls being monitored? Be sure to document that regular review. Is there a periodic team meeting to review these sorts of issues? Meeting minutes serve as excellent proof of these controls.
Respond
The Respond function is all about Incident Response. The best way to show how an organization handles incidents is through a ticketing system, especially if there is a specific security incident ticket type. Incident response plans should be tested, and those tests should produce an after-action report.
Recover
The Recover function can include a variety of contingency plans, but the most common are business continuity and disaster recovery. Prior to COVID-19, most organizations rarely had to invoke these contingency plans, but with many people now working from home, there is a lot of hard evidence around the use of business continuity plans. What worked? What didn’t? How was the plan changed? Hopefully, all of this valuable information was captured and documented. There has been a good deal of adjustment to the new normal. The effort spent should be leveraged to its fullest extent.
Conclusion
So now that we have all of this evidence, where does it go? Perhaps your organization could implement a Governance, Risk, and Compliance (GRC) tool. These can be spendy and can often require one or more FTEs to run, but they provide great organization, accountability, and keep organizations prepared for audits. Another solution is to use a security control matrix and to list the artifacts and evidence for each security control employed.
In the end, it matters less how control validation is done, but more that it is done. There really isn’t any secret sauce. Control validation simply requires that one extra step of taking the work that is already being done and documenting it in a useful way to prove that it actually happened.
Need to validate your controls? Summit can help. Learn about our capabilities here.
