We previously discussed data-centric security and the need for airtight defenses. Using IDS and IPS is a first step in that direction, but let’s take things further by creating overlapping controls that will tighten security much more.
The risk-control matrix is at the core of security planning. The matrix maps our risks to the controls we plan to apply. It’s not a revolutionary concept, but doing it can be challenging. To make the discussion less theoretical and more practical, we’ll take a real example from database security and use the Core Audit Risk-Control Matrix.
The Core Audit Risk/Control Matrix
Risks
Listing the risks is the first step in creating a matrix. To ensure we cover every risk and make it easier to map those into controls, we chose to go by database account.
Databases typically have accounts for DBAs, the application, and others. By enumerating all the database accounts, we can ensure we don’t have any holes on the risk side of the matrix.
There are also risks outside of our list of accounts. For example, from new accounts, vulnerabilities in the database that don’t require accounts, database access from inside the database machine, and data copied out of the database.
Next, we need to determine the possible exploits for each account. Generally, any account, including DBA accounts, can be exploited by their owners (an abuse of privilege), a hacker using stolen credentials, or some other impersonation like compromising the account owner’s desktop.
Application accounts have additional risk factors. The main one is a vulnerability in the application. For example, an SQL injection attack will trick the application into executing an SQL it’s not meant to run. Another risk is an unapproved change that went outside the change control process.
The added benefit of listing risks by account type is that this is also how we control them. From the database perspective, a DBA session is a DBA session. The database cannot distinguish between the real DBA and a successful impersonation. In that sense, there is little difference between a DBA abuse of privilege and an impersonation – in both cases, the DBA account executed malicious activity.
Controls
Each risk should have controls in response. The trick to tighter security is to have multiple controls that overlap. Let’s look at some examples:
The first level in Core Audit is identifying changes in configuration, users, permissions, objects, etc. Other than validating change control, this type of control will identify some attack side effects. For example, if a hacker creates a user for a backdoor, creates a table to exfiltrate data, and more.
That is, obviously, not enough, and at level 2, we can create reports and alerts on specific sessions and SQLs. These controls are efficient for low-volume activity. From a DBA account monitoring perspective, we could monitor for DMLs, DDLs, and access to sensitive tables. Looking at the application account, we can check for sessions originating outside the application server. Reports on other application activity are better left for Level 3 as they’ll be too high-volume to be effective in Level 2. These controls won’t catch every attack, but it’s a good start.
At level 3, we have Anomaly Analysis, which identifies changes in the behavioral activity profile. It’s an automation that can scale to extremely high activity volumes. That makes it a powerful and effective control over application activity as it tends to be repetitive. It can also eliminate repetitive SQLs from DBAs and point out new ones. Another use is analyzing activity sources to identify individuals connecting from different machines, programs, at unusual times, and more.
Another capability in Level 3 is Proactive Forensics, which gives security personnel visibility into who’s doing what in the database. Personnel can investigate activity sources, the amount of data accessed, the ratio between SQLs and rows, and more.
And that takes us to Level 4, which is preventive. Here, we need to be careful not to block legitimate activity. Those are the false positives that are problematic in IPS. But we can still block certain activities like DBAs accessing sensitive schemas, a sensitive table accessed from outside the application, enforcing separation of duties, and more.
Overlapping Controls
As you can see, each risk column has many potential controls, each addressing a different aspect of the risks. We can have multiple reports and alerts that address the same threat from a different perspective. We can also have both preventive and detective controls calibrated to different sensitivities.
We also used 5 different types of controls: Level 1, Declarative auditing (Level 2), Anomaly analysis (Level 3), Proactive Forensics (Level 3), and Preventive (Level 4). Each type has different strengths and weaknesses, like time investment, involvement of security personnel, visibility, prevention or detection, and more.
These overlaps are what make this type of security much tighter. While you probably won’t deploy too many reports and alerts, you can plan on deploying them based on the false positive rate and how much time you can devote to this security.
Applications
And we can also take things further and deploy similar defenses on the application. These are application activity controls independent of the database controls discussed in this article. Declarative auditing, Anomaly Analysis, Proactive forensics, and more – all work on application activity profiles.
By adding additional controls over the application, we will further reduce the risk of an application vulnerability. That will add additional barriers between an attacker and the data.
If you wish to know more, contact us at info@bluecoreresearch.com
