Have a look at this painting by George Seurat. Its a beautiful scene, no?
While the paining looks like an organic whole, its actually a great example of pointillism -a "technique relies on the ability of the eye and mind of the viewer to blend the color spots into a fuller range of tones."
if you zoom in on a pointillist painting, you can identify how the contrast delivers a synthesis in the painting.
At this point, you might ask - fine, but what does this have to do with security architecture?
In a perfect world, its preferable to define a design for security services, and as projects go production then to have security architecture emerge, fully formed, to deliver capabilities based on business and technical requirements.
In the world we live in, many of the high priority issues are driven not as much by technology, threats, or even business requirements. Instead a lot of the Information Security team's agenda is driven by Audit. This is often used as an excuse for not delivering on this or that security service, but Audit shouldn't be viewed as a burden, indeed it can be viewed as an opportunity for improvement. For one thing, Audit elevates you to a fundamentally different discussion level. Audit has a strategic gravitas that most infosec tactical operations lack. The challenge then becomes - how to use Audit's strategic locale in the organization to foment better overall security?
One of the main challenge with Audit is the "checkbox Olympics", long, unblinking Excel spreadsheets that do not appear to dovetail with security threats or capabilities. But with some analytical elbow grease, its possible to alligator wrestle Audit requirements into something that resembles a set security architecture capabilities that benefit your enterprise. The main analytical tool to do this is a Threat Model.
Let's take the much-maligned PCI DSS. No doubt the set of requirements in the standard would not be everyone's top 100 security controls. But that does not mean they are useless either.
In fact, there is a fair amount of optionality to be found in the standard. That optionality grants the security architect some degree of latitude in how they can seek to answer certain requirements.
So a simple way to express security architecture capabilities in the context of a threat model is as follows:
Threat | Sec Svc | Data | App | Channel |
Spoofing | Authentication | SAML | TLS (one way) | |
Tampering | Integrity | SAML | ||
Repudiation | Monitoring |
Logging, SIEM |
||
Information Disclosure |
Encryption, Hardened Interfaces, Defensive Data handling |
SAML | TLS | |
Denial of Service | Availability | |||
Elevation of Privilege | Authorization | RBAC, ABAC |
One mistake made by infosec teams is that there is no single or set of security architecture views. That means the first time an end to end model is attempted is based off the Auditor's check boxes. If you do that, you do not end up with Sunday at the Park with George, you end up with a bizarre blizzard of random, disconnected dots. Like someone threw up all over your canvas.
Instead of the auditor's check boxes, the first cut is to define the current and potentially desired target state capabilities as above table shows. Then the Audit requirements get brought into the current/future capability context.
Let's take an example with some illustrative entries from sections 3, 8 & 10 of PCI DSS. Map each requirements to the threat and potential types and locations of the defense.
Threat | Sec Svc | Data | App | Channel |
Spoofing | Authentication | 8.1, 8.3 |
8.1, 8.3 SAML |
8.1, 8.3 TLS (one way) |
Tampering | Integrity |
10.5 SAML |
10.5 | |
Repudiation | Monitoring | 10.2, 10.5 |
10.2, 10.5 Logging, SIEM |
|
Information Disclosure |
Encryption, Hardened Interfaces, Defensive Data handling |
3.4 SAML |
3.4 |
3.4 TLS |
Denial of Service | Availability | |||
Elevation of Privilege | Authorization | RBAC, ABAC |
The result is a range of options - we can identify gaps, and find capabilities that are in place already or planned. This helps "tune" the security architecture by finding where to double down on existing efforts and harmonize previously disconnected security efforts.
Audit is viewed as subtractive, but like pointillism, there is opportunity to bring it all together: "Painting is inherently subtractive, but Pointillist colors often seem brighter than typical mixed subtractive colors. This may be partly because subtractive mixing of the pigments is avoided, and partly because some of the white canvas may be showing between the applied dots."
Don't let George the Auditor crush your security initiatives, let him help you. Its morning in infosec, time to pull on the boots, and get to work.
Comments