A Framework for Security Reporting
Did you know FICO is a company, not an acronym? FICO, originally Fair, Isaac and Company, provides data analytics focused on credit scoring. FICO influenced the consumer credit risk industry so heavily that its name became the de facto measure depicting consumer credit risk. Enter in SICO (sī-kō), an reporting framework enabling the depiction of business security risk.
In June of 2019, I attended Gartner’s Security Risk Conference in Maryland. I was introduced to a company providing a ‘FICO’ type security score for virtually any major company with an internet presence. The score was assigned to a company by scanning their internet interfaces and determining their risk based on their vulnerability exposure. Were their external interfaces wrought with MS, Linux, or application vulnerability exposure? Was DDoS enabled? You get the idea. Any company could access their reporting UI to determine if 3rd party ‘x’ or ‘y’ was suitable to business with. It also reported company vs. company performance. Sign-up to gain access to an itemized list of resultant security tests performed against your external network interfaces. To improve your score and maybe provide a value proposition over the company ‘y’ fix what they deemed a security risk.
I thought this idea had immense potential with my client, who was implementing a culture of dev-ops and moving into Azure. Given Azure’s tagging and API capability, I imagined a dashboard providing the dev-ops teams their SICO (business security risk) score. It would provide a team-to-team comparison. Each team could access an itemized list of resultant security tests performed against their assigned assets (application code, network interfaces, compute, etc.). Teams would get to ‘see’ what Information Security thought was and was not risky.
SICO, the idea, first came to life through Azure Policy. In the article Power-Up Azure Policy — Turning Azure Policy Into A Risk-Based Tool, I explain how to contextualize Azure Policy data, subsequently improving its value for your IT peers. My Azure Policy work exposed the data schema for SICO, enabling business security risk reporting for your IT peers. The schema is shown below.
For reporting to add business value, these tests' results, specifically each ‘asset’ tested by these tests, must be mapped to a dev-ops team. With Azure’s ability to enable dynamic queries of assets and their resultant tags, mapping findings to dev-ops teams becomes easy. This assumes that you have a tagging strategy where assets are tagged to dev-ops owners and tagged with resultant business value. If not, do that!
Here is an example of an external pentest of a URL.
In Azure, I can look up what asset the URL is assigned to, enabling me to find the owner and the criticality. Based on test importance and asset criticality, the risk of non-compliance can be calculated. We’ve just added dev-ops team, asset criticality, and resultant risk to our schema. I know, for all you hard-core risk people, you notice I am leaving out probability, etc., but my goal here is to solve the quick, easy win!
How about another example based on vulnerability reporting.
Or another based on logging compliance.
What I wanted to show is that Information Security has the ability to add tremendous value to its’ IT peers by sharing its’ context of what is or isn’t secure. Information Security can report not just Azure Policy compliance, but vulnerability compliance, log setting compliance, external pentest pass/failure compliance, all via a straight-forward reporting schema. This is SICO. Good luck on your journey!
PS. If you report on your peer's success, or failure, and especially for failure, be sure to provide a URL link on why the test is important and how to come into compliance. Otherwise, your bosses may be happy, but your customers won’t!