Why risk management doesn't always work

I really believe that information security is about the business and we need to bring the business together, specially when doing risk management. But doing risk management together with the business is not always pretty and easy. There are two factors that can make it a real nightmare: The "pointy-haired boss factor" and the Threat Level business point of view.The pointy-haired boss factor is easy to understand if you read Dilbert and you feel that those characters are really based on real people. Remember that sometimes people that we call "the business" are people like the pointy-haired boss, not only on their intelligence level but also on their way to find "smart solutions". I can remember a dozen situations where a security issue was exposed to a business person and this person decided to "solve" the problem in a weird way, usually bringing more problems than solutions.Besides dealing with stupid people (don't you feel they are everywhere?), there is another problem that often appears when we are doing risk management with the business: the Exposure Factor. As we know, Risk can be translated into  Probability of Occurrence x Impact.  The probability of occurrence can be seen as the result of two factors, Threat and Vulnerability.  Information security  professionals usually provide these factors during a risk assessment, but the business usually want to put their opinions about the Threat Level.  This that famous "nobody will try to do that" line. Even with all our knowledge about what's happening around the world, they still don't believe in the information we provide. So they will mess with the calculations in a way the numbers will be more like their beliefs. The risk based decisions are compromised.Risk management can't be done without the business. However, when doing that, beware of PHBs and TLBPOVs. They can ruin everything.

Cold boot attacks against disk encryption

Everybody is talking about it. It's really a very nice piece of work.However, I noticed that almost nobody is talking about mitigation strategies. It's clear that the only way to "solve" the problem is to use a different hardware archtecture, something like "tamper proof" memory. However, there are thousands of organizations using disk encryption and they will ask us what they should do now. My tips:- Check if the software you are using have the proper controls over the encryption keys after the volumes are unmounted. The main options in the market will behave properly about it (erasing the keys from memory after using them), however, it's important to be sure about it.- Instruct users to avoid "sleep mode". Some computers have BIOS options to disable it too. This will reduce the exploitation window by reducing the time where keys are in memory and memory is powered. Remember, the data will last only some minutes after powering off.- Set up a BIOS password and configure your boot sequence to always start from the hard drive. I know that there still the option to remove the memory chips from the computer to read them elsewhere, but it's not as simple as connecting a external hard drive and rebooting.  Alternatively, you can turn on the memory test of the POST sequence, it will erase memory content too.Besides that, it's important to mention that the probability of the attack still is not very high. The image of someone going into an office and doing all that procedure from the video is more like a "Mission: Impossible" shot to me. Of course, those with very valuable information (like Intelligence agencies) will have carefully to think about this issue.

RSA, here I go!

From yestarday's edition of ISSA E-News:"2nd Winner of Free RSA Conference PassesEnter Now for February 29 DrawingAugusto Paes De Barros, a security consultant for Tempest Security Intelligence and Projects Director for the ISSA Brasil Chapter, is the second winner of a full conference pass for RSA Conference USA 2008. The drawing was held on February 18.This week is your final chance to win a complimentary full conference to the conference, scheduled for April 7-11 in San Francisco. The last two passes will be drawn on February 29. Enter by completing the entry form on the ISSA website, https://www.issa.org/Members/RSAContest.php. Your ISSA ID number and password are required for log in.Those selected will receive email notification from ISSA International following the drawing. Results will be announced in the next issue of eNews.Winners will be responsible for their own transportation, lodging and incidental expenses."

Data stolen from Petrobras

The Brazilian news are all talking about the report of data being stolen from Petrobras, the Brazilian Oil Company that is growing a lot based on recent oil reserves discoveries near the Brazilian coast.The problem is that the data stolen is technical information related to those discoveries, and it was under custody of Halliburton. In fact, hard disks and laptops were stolen from a Halliburton container being transported to one of Petrobras prospection bases.One thing that is being discussed is a possible conflict of interests on Halliburton working as a Petrobras service provider. Halliburton is constantly accused of doing lots of things (specially by Michael Moore), so the news immediately caught the eyes of lots of people.  Prospecting oil is a Petrobras monopoly in Brazil, and there is a business model where the company hires partners to work on specific spots. The information about the potential of those spots is probably very valuable to those companies with intention to participate on the auctions where those partners are chosen.

Another botnet following our predictions

Now it's MayDay. Among the things we predicted in our BH presentation:- Using Proxy enabled HTTP- Using ICMP and P2PAlmost all of our predictions came true during the last year. The most scary ones, however, still haven't appeared. Let's see what happens this year.

Security by obscurity, a little more about it

Daily Dilbert today has a good sample of the discussion of security by obscurity. It's rather obvious that it doesn't bring much protection when used alone, but some things seem to be useful, like the case on the strip.As a quick comment, an interesting Information Handling Policy I saw once instructed that sensitive info should be into a envelope with the "Confidential" label, but this one should be into another common envelope, to avoid the label catching the eyes of an eventual spy.

Client software vulnerabilities, watch out

The SANS ISC mentioned that today there are patches available for Adobe Acrobat, Firefox and QuickTime. Next Tuesday there will be a bunch more from Microsoft. So what?Try to find a Windows box that doesn't have one of them installed. That means that during these days almost all Windows boxes will be vullnerable to one or more client side vulnerabilities. Considering that most users don't have the habit of updating other software besides Windows and that most organizations are not considering some of those products in their patching processes, we can see why client side vulnerabilities are the new venue to be used by smart attackers.Take the time to check the software inventory from your workstations and compare it to your patch management capabilities. I bet that the new major worldwide security incident will be based on vulnerabilities from those software.

Quickly deploying security: Decision Gates

"Decision Gates define major control points that are used to move from one phase of the project to the next. A control gate is used to determine if the products for the current phase of work are completed based on the criteria set out at the beginning of the project and that the project is ready to move forward to the next phase. Controls are used to get formal sign off of that phase of work by the system’s owner and management."Ok, so you need to deploy security controls and processes. Try to identify the decision gates inside your organization. They are everywhere: change management, application development, hiring process, aming others. Decision gates that already exist are the best places to include security assessments and verifications. You don't need to change established processes, just include some checks on the decision gates. One thing is very important, however. Remember to clearly define the pass/fail conditions, the exemption process and to get some empowerment to be able to participate on the decision that is made on those gates. Without that, you'll just be documenting risk, not controlling (and managing) it.

Mainframe security - finally I found someone talking about my concerns on it

I was doing some research for references to include in an article that mentions "Mainframe insecurity". One of the reviewers of the article challenged some of my comments on mainframe security. I finally stopped after googleing for some minutes at Cat Slave Diary. The most interesting thing, for me, is that the author mentioned some of my main concerns on mainframe security, specially the connections with applications running on other platforms. You can find good posts here and here.

The discussion of the moment: A versus C-I-A

Well, it's funny to see this discussion started by Farnum about "Availability versus Security".  I remember seeing one of the first product presentations from Symantec after the Veritas deal. It was the first time that I heard someone saying something as "there is Availability and there is Security". I remember the guy showing one of the famous "circle slides" with two halves, one representing Availability and other Security.At that time it was clear to me that they are showing that only to justify the merge between Symantec and Veritas product lines. And if you take a look at the article that started all the current discussion, you will see Symantec there. This "segregation" between A and Security is part of their marketing strategy.I think that there is space for this segregation. Let's face, the skills needed to someone working on High Availability and Business Continuity are quite different from those used by the regular Security professional. I still think that security assessments and strategies need to take A into account, but I don't see a problem if the controls and initiatives to deal with those risks are being conducted by others. I can't see, however, how to talk about Security without talking about Availability.  After all, it's part of Information Security definition. So, let the other IT departments deal with implementation details of things like clustering and backups, but don't forget to include Availability risks on your assessments, even if it's not your direct responsibility to mitigate them.I believe that Availability is a very good sample of what lot's of good minds are predicting about security: the controls and solutions will be integrated by other IT things, like Intrusion Detection in Switches, Antivirus and malware detection on endpoint solutions also used for software distribution and configuration, and so on. It will happen to lots of things, but it doesn't mean that security will vanish from companies. Our job will be more on assessing and planning that on deploying solutions.Good parts of the "availability discussion" are here, here and here.

Should we let consultants use their own computers?

The question was raised, again, because of this.A funny thing about the discussions about it is that everybody is always right, in a certain point of view :-)This is yet another case where several other variables need to be assessed before a decision is made. A company where the business requires lots of third parties with access to its network and data won't be able to cope with a policy that denies the use of third party devices. In those cases a study to compare the cost (and viability) of compensatory controls (e.g. NAC, device checking policies, DLP) and option of having hardware and software reserved to those people is the best way to go before choosing a way to go.Some companies have most of their employees working in fixed positions and just a small need for mobility and third parties computers accessing the network. For them, the Policy denying the use of the devices (and even the use of controls to avoid it) is quite reasonable.This is just one of those decisions (almost all of them?) that need to be taken together with the Business.