Saving Money with IT Security Processes. Example 7/26: Early Notice of Regulatory Compliance Changes through Technological and Legal Watch

Article number 7 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Regulatory Compliance requirements are a pain in the back for companies. They've got to reach some government-imposed or industry-imposed requirements and they sometimes have to reach them by using imposed means, tools, technologies...

However, the most costly is not to put the requirements in practice if you know them from the start of projects. The most costly is to modify production afterwards, in haste, in order to comply:

• The production may incur downtimes and bugs because of the hasty patches.
• Besides, the architecture may have to be reviewed to support the requirements, and the previous architecture may be obsolete before it has paid off.
• Eventually, the patched system may be more expensive to operate than if it had been thought about correctly from the beginning.

A good way to prevent such blunders and losses of money from happening is the Technological and Legal Watch process. The goal of the process is to identify emerging threats. Threats can be:

• Technical, like a new vulnerability.
• Commercial, like a vendor no more supporting a product.
• Trends, like the emergence of a new kind of attacks (think XSS a few years ago).
• Regulatory, like the validation of an industry standard.
• Legal, like the imposition of a new legal requirement.

The best tool for Technological and Legal Watch process is the RSS feed. Feeds can be collected from related web sites. Feeds can also be created from Google searches (with keywords).

Identity Management Steps, from the Ground Up

Norms and legal compliance often require companies to do strong authentication. But it must not be forgotten that strong authentication is merely the cherry on top of the cake.

Strong Authentication is an improvement upon Authentication, weak or not. Authentication is built upon a correct Identification of people. Identification allows for Authorization based on rules, for instance, ORBAC or RBAC.

Or, if we put it into natural questions:

1. Who are we speaking about? Identification
2. And who's that? What's he supposed to be doing around here? Authorization
3. Let him prove he's really who he means! Authentication
4. Let him prove that he's not cheating on authentication! Strong authentication.

Strong Authentication Authentication Authorization Identification

The most important is to understand that a compliance requirement about Strong Authentication is only the tip of the iceberg. Any project targeting Strong Authentication should first concentrate on cleaning and validating Identification (list of users → list of all users → list of all users individually identified → up to date list of all users individually identified → up to date list of all users individually identified with all information related to their work assignments and related Authorizations), then choose specific areas among all possible Authorizations (among the many things people are allowed to do in the Information Systems, which are now to be protected?) and then enhance Authentication into Strong Authentication.