In having a discussion today with a colleague about security architecture and SDL governance it struck me how hard writing proper security requirements is.
If you look at a standard such as PCI it jumps all over the place from high-level strategic (prevent intrusions) language to exacting specifications of how long passwords must be and what encryption algorithms and wireless security mechanisms must be used.
Compare PCI to another fairly comprehensive standard such as ISO-17799 and you'll be surprised how high-level and imprecise the ISO standard is.
In developing a set of security policies, standards, and then working with teams to specify project specific requirements we're often torn between specifying the goals we want to achieve, and the exact mechanisms and implementations that we believe will meet those goals.
The larger the organization gets the less often you'll get to be involved in a given project, interact with a given team, etc.
Its a tough balance to strike however between the security organization over specifying and under specifying.
In general we want to have fewer components, solutions, etc. to audit, have assurance over, etc. At the same time trying to standardize everything, especially in a development organization, risks killing the exact innovation you're trying to encourage.
There are certain cases where a regulation or auditor is going to force a certain standard on you that seems too specific to be in a high level standard or policy but which nevertheless is mandatory. This is why you find some many policies that specify exact encryption algorithms, exact wireless security mechanisms, etc. In a regulated arena you really don't have a choice but to make these standards.
Given my choice though I'm torn on where to draw the line between specifying basic security properties that each product/feature/system must meet, and writing requirements and standards so specific that only one technology or solution could possibly be judged compliant.
No comments:
Post a Comment