crowmoor.se

I suppose everyone have heard about Echelon, the big information collecting system that is supposed to monitor all communications to and from US (and possible everywhere else). The information mass must be gigantic to handle. But looking at it from a bit smaller perspective Corporate Echelon is starting to happen.

Looking at the trends in corporate security monitoring and surveillance are rising stars that starts collecting humongous amounts a data. System after system is monitored where the following information is collected: who accessed it when, what did they do, what did they do wrong, what did they ask for and so on. All this information is gathered into a log collection system and then what?

Here comes the interesting part from my experience. Security is run by people and suddenly we have stumbled into “Who watches the watchmen?”. When working with reviewing logs and doing investigations you could possible get a very good grip on a person. Monitor their e-mails and you learn about their spouses, family, mistresses or lovers, friends and so on, monitor their web browsing and you learn about their interests, sexual preferences, hobbies, fears…

And here is the dangerous stuff. Unregulated reviewing of logs could lead to privacy intrusion. I have seen “Security Hangman” (the security person who always says no and knows everything about everyone) rule a company with an iron fist knowing everything of all mergers, acquisitions and having the possibility to black mail everyone in the board. This is dangerous and sadly not that uncommon. Even if most security people are good natured and only wants to protects his/hers colleagues from harm some things should not be looked at if not needed.

And here comes the important part. Always base you need for analysis on risk analysis. Logging everything is needed for making a good investigation but do make a risk analysis and identify the patterns of a security breach. Insert the patterns in the log collection system and have it pop up alerts when a threshold has been reached. By doing this you actually get value of our log system and could act quickly. You could actually set up automated responses as well. This means that you have to have an ongoing risk analysis process that works with pattern identification and you also need to set up an ethical board to handle the questions that arise when doing an investigation because you are bound to find stuff that a single person cannot handle.

Just read an interesting blog entry from Apache Infrastructure Team.
Apparently they had a breach in security that hit them with some downtime. What catched my eye was that they are very open with what have happened in contradiction to the ordinary secrecy in security where one is seldom even allowed to say that you work in the field of security and even worse who your customers are.

Lets take a look at the assumptions behind secrecy:
1. Avoid embarrassment
2. Not divulge any information
3. Not scare the shareholders
4. Mistrust

Any kind of breach does more or less always include a downtime. For a very frequently access site this means it WILL be noted. It is of course possible to say that a server malfunctioned but that will lead to demands from customers and partners to create failover functionality and other solutions that actually do not address the real problem. The embarrassment for the site being down will be there in any case. Is there an embarrassment for someone exploiting a vulnerability? Yes, in some cases there are but most of the time the reasoning goes: It happens, fix it. Most important is to contain the breach, not let it run its course.

As for not divulging information that is a flawed assumption. The attack has already happened, information of the attack is spread in the hacking community and all those that you don´t want to have the information of your setup already have it and even worse have access to the servers.

Not scare the shareholders (or the public in case it is governmental) is a tricky one. When looking at share holder psychology speculation is often the biggest threat and information is often the biggest remedy. That leaves us with: inform the shareholders. If there is a rumor that the site has been hacked you could be sure that the stock will go down and that is bad.

Mistrust is a difficult one. Who is to mistrust? Quite often I have run into that the security department mistrusts the people in the company instead of working as a support unit for them. So by not trusting them information of the incident is kept secret and a false shimmer of safety is put on top a raging fire. Real security is about trust. Information regarding incidents has to be available for the management so that they could assess the risk at hand.
So what are the lessons learned from the current incident? Trust in Apaches competence to fix incident have risen. It turned out that they were running Apache web servers (no-brainer). Confidence that there products are safe and stable as they provided exact information on who the attack was done (exact enough, not into every nitty-gritty detail).

So as long as you have a low amount of incidents, a good security architecture that mitigates the threats in the first place, and a good incident and follow-up routine you should inform about incidents.

Finally WordPress have come around and fixed the spam problem. I´ll test and see if the problem arises again. But as for now feel free to register.

When I am out and about speaking with customers and suppliers I often run into the question of cloud security and what that really is. The discussion always starts from the point of perimeter protection, access control to the perimeter and so on and that is not always the solution for cloud security.

When we look at services in the cloud we have some new threats to handle. First of all you have the whole of internet that in some way or another have a possibility to access your information, you have some unnamed operations personnel at the cloud supplier and finally you have the possibility of your cloud supplier going out of business, network problems or other similar problems with accessing the information.

So how do we handle this? First of all you have to make sure that the application is build securely. As the application is used by other entities as well it is exposed to more attacks. If it contains vulnerabilities they will be found faster. So make sure the application is built using SDL or some other secure development method. The case of operation security is quite interesting. If you information is valuable for you it is very possible that it has a value for someone else. Make sure that the personnel at operations cannot access your information. This is easiest handled with encrypting the information objects and handling decryption at your site. As for the availability, make sure there is a backup offsite from the cloud supplier and that you are monitoring the financial status of the supplier.

I will attend Strategitorget Identity and Access management the 30-1 of september/october. If you plan to attend please feel free to contact me. I will be running a workshop on thursday. During the whole event I will focus on the business value of IAM and how you measure the value from a risk/cost perspective.

Backup´s are important as we further enter an automated world where IT is essential in the business. I used to work with designing manual procedures in case the IT stopped working but during the last few years I have stopped doing that due the fact that it has become more or less impossible to do the work manual due to the integration of it in all processes.

This leads to a other kinds of problems that seldom is addressed: backup chains. What is a backup chain? In short it is backing up a process rather than backing up a system. When you have a transaction moving automatically through several systems and you have a failure somewhere how do you make sure that you do not loose transactions, have them entered in the wrong order or recreate them in case of a disaster?

It is very common to have a backup system that backs up the database and it is possible to select the precise second to restore to. Sadly that is not precise enough. It is very common that the restore is performed flawless and the system goes back online but still the process fails due to errors in the transactions making applications hang, customers lose their orders or payments and so on.

By working with backup chains and designing the recover after the process it is possible to restore the process in case of disaster. This would of course be a simple task if the process was constant and seldom change but that is not the case anymore. Process on the fly, as described in Technovision 2012 has to be supported in the backup chains to be able to recreate the transactions. This is of course a major hurdle in the process of securing the availability of the processes but not something that is impossible. I have been using availability chains during several assignments to document the possible availability and find the possible flaws in transaction chains that could pop up in case of trouble.

In the end there is always a cost and rather often the automation has been done without having confidentiality, integrity or availability in mind. Inserting this afterwards could open up for a load of costs if not done with an understanding of the business need for availability and the technical constraints created. Time to roll up the sleeves and start thinking on security architecture. 🙂

The tragic death of a famous artist opened up a flood of messages at Twitter. It peaked at 5 000 messages/minute. As with all tragedy’s there is always rumors that says the opposite, in this case that the artist is still alive, and refers to a link showing evidence. In this case this has proven to be a bigger problem in Twitter together with other similar sites. There will most probably always be sites containing malware but with Twitter they have found a way to mask the address due to the fact that Twitter use short links instead of showing the real link. The problem with this is that the user cannot make an informed decision if this site is trustworthy or not and in conjunction with reactive protection system that hasn´t been updated for a day or so the infection spreads like wildfire.

The real question is if there is a way for us to protect against this. One thing is to never click a link on Twitter or anywhere else short links are used. I do understand the need for using them as communications often is done with SMS but still the security threat is there. I myself never click short links but that is not a working solution.

Most probably we need to look at other ways of protecting the users as we cannot rely on the users to not click on links. One way could be to use virus protection from the cloud and/or malware protection using a proxy from the cloud. Local antivirus is just not working anymore.

Just recently a link with an ID protection solution was sent to me. Apparently it checks all over the globe (at member sites of course) for use of your identity. If it is used somewhere you are immediately informed and have the possibility to take action. As identity is the most important aspect within security I applause such initiatives when they submerge. Still there of course are problems. Still we do not have only one identity, we have hundreds. Me myself have at least five or six connected to financial transactions, pensions or legal (at least two factor authentication of course), and I do not know how many I have at different sites.

Of course there is a need for private identities where I would not like to include my personal life with my work. For example my employer maybe do not like that I am a diver due to their need for my competence, therefore I do not tell them and by using a private identity that is not connected to me as a person I cannot be googled or in any other way be exposed with a connection (if I do not accidently post it on my blog) ;-).

Hopefully we will see more sites connect themselves to OpenId and other solutions that make it easier for me to see if someone tries to steal my identity. Hundreds of sites make it impossible to have a simple surveillance of when my identity is being used. A few ID repositories are the way forward.

In a Swedish newspaper today there was a rather interesting article regarding The PirateBay-trial and all events surrounding it. Apparently Henric Pontén got his named changed to Pirate Pontén. The interesting part in this is that you could have your name changed without any authentication at all. Someone only needs to send in a filled in form.

When looking at this from a security architecture point of view this is an attack on the underpinning structure of all security: the identity. Of all things that need protection the identity is the one most important to protect because without that you lose all integrity of your authentication mechanism. This means that changes in the identity needs to be protected with very strong security mechanisms.

Our current example shows us that the underlying structures and mechanism of identity in the government still need some polishing to be able to use as a trustworthy identity mechanism.

During the last years I have had the opportunity of acting as a mentor for security professionals, CSO, CISO and others. My area of focus has been making security easy to handle and understandable for the common man. It is almost amusing to see the changes in how a company works with security before and after I have helped them.

The main difference is taking the step from a controlling security organization where security is viewed upon as something necessary but costly (or worse unnecessary) to an organization where security is risk based and where there is a respect for not breaking the laws and a competence to communicate the value of security in the costs of not handling it.

This may sound as a very logical and simple approach but in reality this journey could be very complex. It is not uncommon that security is governed by fear and the need for fright to work. This leads to a security organization where everything is forbidden and the tools for supporting the business either are completely locked down or worse are out of IT-departments control.

Making this change is all about changing the mindset how security should be used within the organization. Without knowledge how security really works and the tools to support it is almost impossible to create the possibilities for change. Security is a mindset, service is a mindset. The big issue is how to bring them together.