Please Don't Break Tabbed Browsing and Browsing History!

Tabbed browsing or the ability to browse websites in multiple tabs at the same time is now an acquired benefit. Yet, it can be broken if ill-designed websites just try to mess with it.

Basically, when you click a link, the address of the link gets copied into the address bar of the browser and you access that address. If you open the link in a new tab (middle button on the mouse, usually), the address gets copied to the address bar of the new tab. Pretty simple, huh?

But some sites try to add scripts that tell your browser where to go when the link is clicked, instead of just doing the normal way. So, they mess with the regular work of the browser. Three kinds of bugs can then be encountered:

1. The link opens both in the current tab and the new tab.
2. The new tab opens but the linked page doesn't show in it.
3. The browsing history gets broken, preventing you from correctly returning to the previous page.

So, here is my point:

STOP MESSING WITH LINKS!
STOP MESSING WITH BROWSING HISTORIES!
Just let users open what they want where they see fit.

Example:
Viadeo, a French kind of LinkedIn, is doing it. If you middle-click a link, it will open both in the current tab and in the new tab. Thank you developers! Let me add that this is particularly inadvisable for a social network, where the most valuable users are very experienced and open dozens of tabs at once.

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

Two Security Policy Writing Tips

Reading Anton Chuvakin's On Nebulous Security Policies reminds me I wanted to share two very simple, basic, common sense, advices about writing the Security Policy.

Although norms like ISO27000 may give good guidelines to the content you put into the Security Policy, it would be quite suboptimal to write nothing more and nothing less. You have to adapt it to your organization and you can benefit from it.

My first advice is:
Stick to what you already have, or almost have. For instance, if you already backup 95% of your servers, you can write something like "all servers must be backed up". That will help you communicate what you already do and obtain more observance from your own teams.
If, on the contrary, you only backup a few servers, don't go into writing that they must all be backed up. That would show that you don't do what you say and that you write things you don't have a clue how to put in practice.

My second advice is:
Think of IT problems actually occurring, where you would welcome help from top management, and write these principles into the policy. This way, the top-management-approved policy will support your efforts to address these problems. For instance, if you would like to clarify that the IT service doesn't support hardware that wasn't bought by the IT service itself, the Security Policy is the right place to state it.

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.

Saving Money with IT Security Processes. Example 5/26: Reducing Help Desk calls and duration with Patch Management

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

The Help Desk is the service provided by people who are there to collect user calls about IT incidents, answer them when possible and, when not, transmit to people who can. A typical Help Desk receives thousands of calls a month. Companies lose percents of their annual revenue in these incidents: incident ⇒ business is down, user (employee) is demotivated + Help Desk must be paid to intervene.

There are three levels of difficulty for a user call handled by the Help Desk:

1. The Help Desk knows how to solve the incident described by the user, or they know to whom they should redirect it. This takes a few minutes and represents an important part of the whole lot.
   
   
2. They don't know precisely how to solve incident nor whose help they should ask for. So they must investigate, take a lot of time to understand the real root of the incident and to act accordingly. Along the time, the Help Desk will build a database of knowledge about these incidents and, so, will improve its overall performance. However, this second level of difficulty represents the biggest part of all calls.
   
   
3. The incident is just overly complex, the Help Desk knows they won't be able to solve the incident, so they just redirect it to the regular IT team and ask for help. This is a small part of all calls.
   
   

Improving on this may seem like climbing an impossible mountain.

However, IT Security can simplify the work of the Help Desk and save company's money this way: accelerate work ⇒ downtimes decrease + Help Desk teams can be reduced. One way is the Patch Management process.
Albeit unrelated at first sight, the Patch Management process keeps your software up-to-date. If it's up-to-date on all workstations, then it's precisely the same on all workstations. Then two workstations will have the same set of possible incidents, instead of two different sets of possible incidents. Now, if the Information System is 30 software pieces on 1,000 desktop PCs, then instead of having, say 5 different versions per software, you'll have just one. So, instead of 30 x 5 = 150 sets of possible incidents, you'll have just 30.

This means that the database of incidents (for level 2 difficulty) will grow faster compared to the total number of possible incidents. So a larger part of level 2 incidents will be treated as fast as level 1 incidents, resulting in a significant increase in Help Desk performance:

• Users will be more satisfied,
• Help Desk will find its job more rewarding,
• Help Desk will save time, that can be put onto something else.

This is a very often forgotten side of security. Most people will just see Patch Management as a protection against vulnerabilities or vendors no more supporting old versions of software, but will overlook the virtuous circle of simplifying the information system.

Saving Money with IT Security Processes. Example 4/26: Identifying SPOFs with Network Architecture

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

SPOF is a very hackneyed expression, nowadays. However, a certainty remains: SPOFs must be addressed, or your company will loose a lot of money in downtimes. To address them, you must first identify them. One of the objectives of the Network Architecture process is to prevent SPOFed architectures to go into production and to identify SPOFs in the existing production architectures.

This, contrary to the opinion of many, is not a lost race. There is a finite number of 4 kinds of SPOFs, that you must all look for:

1. The hardware SPOF: your hardware (whether servers, network equipments, etc.) is not redundant.
2. The network SPOF: your hardware is redundant, but the network links that connect equipments are not crossed. They should normally deserve all redundant hardware just as well.
3. The configuration SPOF: your hardware is redundant, the network deserves it well but the clients are not aware that they should be connecting to the failsafe servers if the main ones are not available. In my experience, this one type of SPOF accounts for a huge part of forgotten SPOFs and related losses in unplanned downtimes.
4. The technology SPOF: one of your technologies fails (whether hardware, software or network). As it is the same in the main architecture and in the redundant architecture, both suffer from the same downtime.

Please read my previous article for sample network diagrams of these types of SPOFs. With a sound Network Architecture process, you can reduce downtimes by identifying SPOFs before crashes occur.

Saving Money with IT Security Processes. Example 3/26: Identifying Low Use or Unused Servers

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

Maintaining servers is often costly. Electricity is a point and complexity is another: various technologies, various network connections, etc. The use a few years ago was to have 1 server per business applications.

The flaw of IT services is often to just let things how they are until something bad happens. But losing money day after day is a bad thing, and you can do better with a strong Supervision process. Supervision of servers must include graphs of intensive values: number of connected users, CPU usage, memory usage, inbound network flows, etc. With these graphs, you can identify:

• Low use deprecated servers and effectively unused servers (happens, sometimes), which you can decide to just stop.
• Low charge but important servers, which you can virtualize. You'll then reduce hardware costs and decrease complexity through homogeneity.