Saving Money with IT Security Processes. Example 8/26: Quick Recovery from Backup

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

Recovering a server or user data from backed up copy is a well known activity in IT. Not doing so would cause huge losses to the company, including downtimes and manual recovery (double work from the end user). However, you can't ensure that your copies will be functional without a proper Disaster Recovery process. The duties of the Disaster Recovery process manager are the following:

1. Include all new data and servers into the saving mechanisms. This may require that backup people be at the conception phase of each project to ask corresponding questions: what's to be saved? How often? How to access it?
2. Test the recovery mechanisms. Although what's backed up is backed up, you may not be able to use it if only a tiny bit of it is missing or backed up incorrectly. So, recovery should be tested at least once for every business applications and recovery machinery and media should be tested very often.
3. Review the list of what's to be backed up. The copying of older applications can be stopped. Newer versions of the same applications may require new data to be copied.

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).

Saving Money with IT Security Processes. Example 6/26: Reducing Project Delays with Secure Project process

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

Projects have a conception phase. In this phase, networks are designed, interactions with users are designed and so on. This is a moment when thinking critically with a security mindset is most valuable.

If you let the conception phase evolve without a security engineer, IT people will think about networks but not about intrusions. They'll think about users but not about attackers. Because that's the security job. So, they will design vulnerable software, networks and/or servers.

Then the vulnerable conception will be implemented and put into production. Then either the Security Audit will spot vulnerabilities and ask for a costly patch (or re-design) or the Security Audit will miss it and a security incident is going to happen soon. Both cases are very expensive for a company.

If you have a sound Secure Project process, with a goal to secure developing projects, this will not happen and the company will save a lot of money.


The whole case in this article is based on two little known asymmetries:

1. You can look for a vulnerability at the conception phase or at the production phase. But doing it in production is longer (more expensive) and is more likely to just fail spotting the vulnerability.
   
   
2. You can patch a vulnerability at the conception phase or at the production phase. But doing it in production is longer (more expensive), may require stopping production (lost business hours) and may trigger side-effects.