Le bienfaiteur anonyme dans le nuage

Je viens d'apprendre l'histoire horrible du suicide d'Amanda Todd, cette jeune Canadienne qui a été persécutée sur les réseaux sociaux par un inconnu qui savait tout d'elle. Pour mieux comprendre l'histoire, autant l'écouter elle-même quand elle présente son cas, peu avant son suicide :



Qu'en dire ?
Le taux de suicide des jeunes est de l'ordre de 0,5 à 3 sur 10 000 dans les pays développés. Les taux de tentatives de suicide sont encore plus haut. Et ceux de comportements à risques mortels en toute connaissance de cause sont encore encore plus haut. Aussi, le suicide en soi ne m'étonne pas.

Ce qui m'étonne par contre pour cette pauvre malheureuse, c'est surtout qu'elle n'ait pas trouvé à rebondir alors que ses parents étaient au courant (déménagements, changements d'école) et qu'elle-même semblait avoir bien conscience du problème.

Facebook dans l'affaire ?
L'internet et les réseaux sociaux ne me semblent statistiquement pas un terreau digne d'un intérêt spécifique dans la lutte contre le suicide. Par contre, le rapport de cette fille en particulier à ces médias mérite d'être étudié. La mise en scène de son propre cas est un phénomène étonnant, proche de la mise en scène du suicide. Non pas un appel à l'aide mais un rejet de la honte sur les autres. Je ne suis pas médecin mais je pense que c'est un sujet d'intérêt.

Surveiller l'usage des réseaux sociaux ?
Des collègues ou des relations qui connaissent mes activités professionnelles m'ont souvent interrogé sur la façon de mieux surveiller leurs enfants. Ils sont inquiets de ce qui peut passer inaperçu sur les réseaux sociaux. La crainte du violeur ou du kidnappeur rencontré sur internet est omniprésente, la crainte aussi que l'enfant ait simplement trop de "mauvaises fréquentations" qui lui ruineraient la vie.

Ma première réaction est toujours de bien clarifier que je suis RSSI d'entreprise, pas RSSI familial. Je suis professionnel, on ne se refait pas.

Ma seconde est de rappeler que rien ne remplace une vraie relation de confiance avec l'enfant. S'il vient demander conseil, s'il ose parler de ses doutes, de ses peurs, s'il ose avouer ses maladresses avant que le pire ne soit arrivé, alors le risque sera réduit de beaucoup. (Note : c'est la même chose en entreprise entre le RSSI et l'informaticien. Une relation de confiance est primordiale.)

Et si le réseau social participait à la lutte contre le suicide ?
C'est une remarque d'informaticien : on sait faire de la publicité ciblée, on sait corréler les informations reçues de divers réseaux sociaux, pourquoi ne mettrait-on pas en place des robots, des applis iPhone, Android ou Facebook, qui préviendraient les services SOS Suicide d'une personne qui pourrait passer à l'acte ? Il y a clairement des signes avant-coureurs qui pourraient être récoltés par le cloud.

Divers cas d'usage et d'utilité peuvent être envisagés :

• Détection automatisée des personnes à risque,
• Premiers secours automatisés ou accélérés,
• Transfert automatisé ou accéléré du cas à des contacts de proximité de la personne,
• Récolte en ligne de données-clés permettant de connaître mieux et plus vite le cas de la personne,
• Prévision de rechute ou de passage à l'acte pour des personnes connues,
• Étude statistique des facteurs clés qui peuvent contribuer au comportement suicidaire (par recherche des similarités entre les cas).

Ainsi, le réseau social ne serait plus seulement l'outil du tortionnaire mais aussi celui du médecin. Plus seulement un lieu où le réseau amoncelé renforce la pression sociale et les préjugés mais aussi un lieu où l'on casserait les cercles vicieux en mettant à profit l'irruption possible d'un bienfaiteur anonyme.

Saving Money with IT Security Processes. Example 13/26: Avoid Misleading Vendor Advice with Security Awareness

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

Vendors are doing their job: they try and sell security solutions and services. Ideally, they prefer to sell solutions rather than services. It's more concrete, more helpful to convince non-security people and it implies additional services in order to implement and maintain them.
In order to do so, they demonstrate the profitability by showing critical examples of security breaches and/or outages. This could be a kind of Awareness if it weren't so biased. It's biased to:

• Concentrate fear on the subject that's addressed by the solution they're trying to sell. (Whereas the subject may not be a major concern for the company nor even a concern at all.)
• Concentrate fear on the little points in the whole subject that the solution actually helps solving. (Letting 95% of the actual subject unsolved.)

CISOs are used to this kind of manipulation. They just go though it without even noticing anymore. For instance, as a CISO, I used to receive every day up to 30 dedicated e-mails from real people I actually met before. I didn't mind.

So, in order to still sell "solutions", vendors attack easier targets: high placed executives outside of IT Security. More precisely, they try and sell solutions wherever the CISO cannot constantly reach:

• IT managers of remote sites where there is no permanent security team,
• Users of packaged "IT tools not considered IT" like Telephony, Document Management, Technical Services from Logistics...
• People interested in closely related matters: Quality, Compliance.
• And sometimes even through service providers!

That's the costly point. If vendors are able to sell solutions, they'll sell unfit solutions:

• Costly,
• Uneffective,
• Ill-centered on minor points,
• Duplicate with what's already implemented,
• Sometimes completely irrelevant...

Through a correct Awareness process, you'll not only touch end-users, but also management. It does the following:

• Communicate around what you already do, → no more duplicates
• Communicate around what you don't do and why (we'll do it later, we don't do it because it's not relevant, it's not a major concern), → no more irrelevant solutions.
• De-mystify buzzwords, → no more ill-centered solutions.
• Communicate about real threats and the associated risk.→ no more haste resulting in cost-ineffectiveness.

Saving Money with IT Security Processes. Example 12/26: Avoid Website Defacement with Vulnerability Management

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

Vulnerability Management is the process that helps your information system stay up to date with patches that fix vulnerabilities in the software you use. One striking example is: with correct Vulnerability Management, you won't get any of your websites defaced.

Please note that it can't be reduced to just using another piece of software to update it all. No single piece of software can possibly fix everything on a regular basis, nor can it fix problems with the best acumen. It's the Vulnerability Management process. It does the following:

• Technological Watch for all currently used pieces of software and technologies. This means subscribing to newsletters or feeds from every single related vendor and reading them.
• Whenever a new vulnerability has been spotted, identify whether the company is affected or not.
• If it's affected, check how much it would cost to suffer from the exploitation of the vulnerability and compare with the cost of applying the patch or workaround.
• Have it put in action.

The Vulnerability Management process is not always identified as a process per se, but sometimes distributed in the Technological Watch and Patch Managements processes.

Saving Money with IT Security Processes. Example 11/26: Avoid a Technology SPOF with License Management

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

What's License Management got to do with SPOFs?

It's got to do with the Technology SPOF.  "Technology SPOF" is the name I gave to all incidents that trigger a failure on all systems of a similar technology. For instance, if two redundant servers share a single storage bay that's full, both servers will suffer the same disk full failure.

Licences are a major source of technology SPOFs. Many products, once their paying period is expired, just stop functioning at all. For instance, antivirus software suites. Many products, once reached their usage limit, also just stop functioning at all. For instance, a dedicated appliance that can host 100 concurrent users.
That's the time when you'd wish you had a sound License Management process.

The License Management process does the following:

• It inventories all current licenses and their limitations.
• It monitors their use so that they don't reach limitations.
• It purchases new licenses in time and quantity.
• It installs new licenses and updates the inventory.

The Licence Management could be seen as a part of a larger Procurement process, however I see fit to put it in Security and not Procurement, because it requires active monitoring, capacity planning and some administation, which are more IT related.

Saving Money with IT Security Processes. Example 10/26: Preventing Massive Outages with Electricity Management

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

Electricity Management is the process that ensures correct availability of electric power for all IT needs.

"Green IT" is the fancy name for it nowadays. We've come to a level of risk awareness where it's common sense that ensuring reduction of consumption and availability of power (that come together, think of it) can make good money for companies. If we can make a point by calling it ecology or eco-friendliness or environmentalism, that's an asset.

To correctly operate Electricity Management process and prevent massive power failures that would cause your company huge losses in downtimes, the following duties must be accomplished:

1. Assess power purchase and power producing capabilities.
2. Put in action a set of load balancing items.
3. Supervise the electric load of all sources. SNMP is a possible choice.
4. Make sure you have recovery documentation for major possible outages.

Saving Money with IT Security Processes. Example 9/26: Preventing the Angry Administrator Revenge

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

The incident that I refer to when I speak about the "Angry Administrator Revenge" is the one that happens when you sack an admin and that he uses his administrative rights to wreak havoc in your Information System. That's a pretty common case:

• Example 1: Ex-Gucci IT Employee Seeks Revenge on a $200,000 Hacking Spree
• Example 2: 10 Ways Fired Employees Got Their Revenge On Their Ex-Bosses / Former Firms
• Example 3: Disgruntled employees may seek IT revenge

This is when the IT Security process of Password Management comes in. (It's sometimes part of a larger Identity and Access Management process.)

Basically, almost everything in IT is protected by a password. Rare exceptions are the things that are not protected at all or the things that require more than just a password. However, password is the rule.
There are two kinds of passwords to be distinguished:

• The personal passwords, that are known by one person only.
• The shared passwords, that are known by multiple people.

Whatever your degree of maturity, shared passwords can't be eliminated completely. So, virtually any Information System in this world has both personal and shared passwords and they give access to virtually every server, storage, application...

The Password Management process does the following:

• It knows who's supposed to know (be in the shared secret) each password.
• It knows how to change them.
• It does change them whenever someone who knows them is no more in charge (or has been sacked).
• And, because there are sometimes more people who know a password than the few supposed to know it, it changes all passwords on a regular schedule, like once a year, or more for critical data.

So, with a sound Password Management process, you can avoid what's happened to Gucci and so many other companies.

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

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.

Saving Money with IT Security Processes. Example 2/26: Retrieving Stolen Smartphones and Laptops

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

Companies lose a lot of money in stolen smartphones and laptops. It does not just amount to the price of hardware, it also includes the quantity of time lost by workers without their tools, the quantity of work needed to report the incident and to, optionally, declare it to the police and to an insurer. Besides, the devices can contain valuable information that the company will miss and that may be dangerous to put on the public place or in a competitor's hands.

It's possible to address the loss of smartphones and laptops with a sound BYOD* process. I'm not talking about a policy, I'm talking about a process, that includes:

• Securing information flows from/to devices with appropriate extranet and telecommuting tools.
• Making sure devices that will save company's property locally do have encryption features, access control features and geographical tracking activated.
• Inventory the types of devices and establish required procedures for each type, because the list is ever-growing, you can't do without managing it clearly.

* I'm talking about BYOD because it's time to face it: most devices are now no longer company devices.

Saving Money with IT Security Processes. Example 1/26: Reducing Virus Crises

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

IT services lose a lot of time and money in virus crises. You can save this time and money with a sound Antivirus process.
I'm not talking about software, I'm talking about process. The process is:

• To have a baseline antivirus, make sure it's configured optimally and installed on every workstation and laptop.
• To have a requirement in RFPs that machines your IT service will not maintain will have a running, up-to-date, antivirus, and to ensure service providers do follow this requirement.
• To analyse unusual network-capable hardware (like tablets, old servers, smartphones, CCTV, storage bays, etc.), inventory them and decide whether they deserve an antivirus or not.

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.

At the Heart of Security: Doing What You Say And Saying What You Do

Security is about deciding what's forbidden, what's allowed and enforcing these decisions.

There's the technical part, doing what you can to technically enforce the decisions.
And there's the human part, managing things in a way that reduces related uncertainties.

The human part is the most important. You cannot enforce every decision technically. Besides, you have to allow for people to switch on/off certain features, eg to allow for good functioning outside of the company's premises. So, you forcibly leave some room for employees to decide by themselves whether they respect the rules or not. And that's the moment when the human factor matters.

The most important tool for the human factor is the security policy. You have to say what you do in terms of security and to do precisely what you say.

If you don't do what you say, you invite people to force the system, they think they can fool you. It may go as far as disregarding completely the policy.
If you don't say what you do, you invite people to rebel and contest the security measures. Additionally, you scramble people's understanding of your security policies, which may lead them to give up trying to respect it.

A l'attention des RSSI : Sur la fuite des mots de passe LinkedIn

Il y a quelques jours, une fuite massive de comptes et de mots de passe LinkedIn a été révélée sur Internet.

Je recommande aux RSSI de faire suivre le mot au sein de leur entreprise/administration.

En effet, comme le site LinkedIn utilise l'adresse e-mail des gens comme identifiant, la plupart des utilisateurs moyens utilisent pour ce site le même mot de passe que pour leur adresse e-mail. Ainsi, les adresses e-mail de ces utilisateurs deviennent des cibles, via les webmails.
De plus, les utilisateurs qui réutilisent leurs mots de passe risquent aussi de les réutiliser pour tous les autres sites dont l'identifiant est l'adresse e-mail. Ces autres sites sont donc menacés aussi.

Exemple : Un utilisateur lambda, Jean Dupont, travaille pour la société Youpeee. Son adresse e-mail est "jean.dupont@youpeee.fr". Son mot de passe est "kevin1502", le prénom de son fils et sa date d'anniversaire. Jean s'enregistre sur LinkedIn avec son adresse e-mail et, pour simplifier, le même mot de passe "kevin1502". Il fait de même sur Facebook. Il fait de même sur Amazon.
De plus, pour qu'il puisse télé-travailler, son entreprise met à disposition un site http://webmail.youpeee.fr où il peut consulter son courrier électronique.


Aujourd'hui son mot de passe LinkedIn fuite sur Internet. Résultat :

• Ses comptes Facebook et Amazon sont menacés.
• Son courrier électronique d'entreprise est menacé.
• Si l'entreprise Youpeee utilise d'autres moyens de télétravail, ils peuvent eux aussi être menacés.

Draft: Stuffing Security into MVC

A long time ago, when I was young and crazy, if I ever was, I used to code components in Java, with the help of the MVC design pattern.

It's a very useful tool and I've recently had the occasion to recommend it to a little company. They used it very efficiently to solve the messy  graphical interface of their featured soft. Nowadays, I'm mostly concerned about security and I do suffer, as those of my kind, from the underlying insecurity of software. It's not just insecure on the surface, it's insecure from the bottom up.


A complex system that works is invariably found to have evolved from a simple system that worked. (he said)
A complex system that is secure is invariably found to have evolved from a simple system that was secure. (let me add).

So I got to ask myself if it was possible to put some security directly into design patterns.

Say you'd like to stuff some of the following principles into the above diagram:  identification, authentication, authorization, audit, capacity planning, soft/hard redundancy, load balancing, cyphering, shoulder spying, data integrity, backup. Where would you start?

For each of them, I'd start by putting appropriate data/meta-data into the Model or near it. Then I'd make the View able to display what's necessary. Then I'd update the Controller with adequate intelligence. Simple, no?


Identification: Identification is based on data that's common with many other pieces of software. Let's say we'll dedicate a new model for it. Then say that neither the view, the model nor the controller will act before the user has been identified.
Authentication: Authentication requires pieces of data, or tokens, that can be verified by interacting with Identification data. But it requires no model of its own. Authentication is -nowadays- a period of time during which the system assumes the user really is whoever is was identified to be. Say that Authentication is a method of the identification component that returns a binary (authenticated or not). Then say that neither the view, the model nor the controller will act if the user is not authenticated.
Authorization: Authorization is a b/w mask (allowed/denied). It's a function of Identification data and the data in our model. So we want to add the "authorization mask" into our model. (That's a huge part of the security job. You can simplify it by using roles, such as in ORBAC.)
Audit: Audit is keeping track of what happens. It can be seen as a two-bit mask of the data in our model, indicating what's going to be logged. 00 means nothing, 01 means read operations, 10 means write operations, 11 means read and write operations. So we want to add the "audit mask" into our model. Then the controller will just write logs of whatever is to be audited.
Capacity planning: Capacity planning is measuring the volume of activity inside the component, as well as the size of the model itself. The numbers of read access and write access to model data and the number of routine execution of controller methods should be counted. These counts can be put into the model and updated by the controller.
Redundancy and Load Balancing: There's not much data in it but the choice of a pattern. Say active/active, active/passive, multiple instances, etc. The choice of this redundancy pattern can be put inside the model. The controller will have to instantiate components and "control" them. This may require an external Timer, or Sequencer, or Scheduler, whatever you call it, in order to trigger events on a defined schedule. (One huge advantage of component programming is that you can play at instantiating them in no time. This part really can be fun)
Cyphering: Cyphering between components is no big matter if you know the basics about PKI. You just need to make sure that you know which flows of data you want to cypher. This can be seen as a one-bit mask (cyphered/cleartext) of component-to-component flows. This "internal cyphering mask" can be put inside the model. Disclaimer: you DON'T WANT to create a unique instance of an object that handles cyphering for every component!
Shoulder spying: Shoulder spying should be let up to the view itself. However, the choice of what data has to be protected from neighbours should be stored in the model. It can be seen as a "hiding mask" (one bit or more). Then the view chooses how to implement it.
Data integrity: Whenever in the history of IT, integrity has meant the addition of control data to check validity and completeness. This data can be put in the model. The controller will have to take on the job of updating it whenever data changes. This means the model will have to enable atomicity of transactions.
Backup : Backup definitely requires an external scheduler because of its high cost. You just don't want to replicate data every time it changes. Plus you may want to rewind time later. Backup can be seen as just a serialization of the model. It means the model will have to support serialization.

More next time...

Can you afford NOT to invest in security in 2012?

 

Crisis is here and it looks like many IT services will get a near-zero investment budget for 2012. I think it's high time that IT services reconsider information security and invest time (if no money) into it. My point is that any security project should open new areas for business expansion and with a positive ROI, like any IT project, security or not.

Security means new openings for businesses

IT services make benefit from selling services (hardware, networks, software, data) to customers, providing an added value to users. Correct security projects allow the expansion of both customers' and users' pools.

1. Users: users are reluctant to use services that are not secured. One good example is the sprout of commercial websites that could not have happened without a *security* measure: SSL.
By adding chosen security measures, you can enhance adoption rate/marketshare of your services. You can also grow the target audience by allowing access to new networks, source devices, telecommuters, etc.
2. Customers: certain customers desire not only security, they demand a warranty about security. That's something you get by two means. One is being sure of yourself and your services (are we up to what we are selling?) and the other one is independent assessment and/or normalization.

Positive ROI for security projects

In a world where security is seen primarily as a source of constraints, the very use of the letters ROI about security is often considered a joke. It's not. For a security project as for any other IT project, you need to invest time and money, there's no reason why security should go without an ROI calculation, and a positive result to it.

In a hard time like 2012, I'd say that you must concentrate on security projects that have an immediate positive return. It's time to focus on projects that cost very little money to implement: the review of processes, of security incidents and the implementation of those "long thought-about but we never had time". It's also time to focus on under-used capabilities of software and servers, instead of re-inventing a costly wheel.
A good security project for 2012 should show immediate returns: less theft of laptops/smartphones, better telecommuting allowing smaller transportation and accommodation costs, better supervision leading to a decrease in downtimes, etc.

As a summary, I think that in 2012 you just should leave out any project that doesn't show an immediate positive return, whether flagged as "security" or not. Just call it technical fussiness and wait for better times.