I was reading a nice post from Gunnar Peterson about APTs. His making the point that everybody is excited about this “oh huge threat oh oh” stuff from the Google x China incident but in fact we should be worried about properly engineering the systems we depend on. I like his analogy of blaming the big bad wolf instead of the house of straws.
But you know what? I think that my current depressed state has changed my way of thinking about security (or changing my way of thinking about security is making me depressed…). I agree with him that the source of the problems is bad security from the deep of the systems we rely on Today, bad (or no) security design in general. But I just think this is a problem we cannot solve. We can see the same issue on several other disciplines, old design and decisions being perpetuated in a way that causes issues to current stuff. However, revolutionary approaches are not (or are almost never) possible due to the way that economy and society works. The technology evolution is also so fast that it would require too many revolutionary processes to solve the recurrent problem of old decisions based on premises no longer valid causing problems to the current state. We simply cannot afford burning everything to ground and start fresh again. All these things are competing for resources and it would be naive to believe we could just choose to build everything with the perfect design.
Gunnar uses the example of the Chicago reconstruction after the great fire. I think it is a great example, but it doesn’t fit exactly his intention. It shows that once something out of your control happens and puts everything to the ground, you have the choice to start fresh and with a better design. Now, how many times have you got the opportunity to start something from scratch in IT? Hey, wouldn’t it be nice to build an OS with no backward compatibility concerns? Ask Microsoft if they don’t dream with that every night! 
Gunnar is asking for something right that is just not practical. Maybe I’m being too cynic and conformist, and I believe we need people who push us to take those revolutionary roads, but when someone does that is usually the exception and not the norm. Those who are dealing with real life issues need to be pragmatic. Yes, we need to protect our straw houses.
What I think is more important from Gunnar’s post is this line:
“The boring stuff is what’s important”
That’s different from trying to re-design everything. There are lot’s of boring stuff that we need to do to protect the straw house My first and main example is access control. IMHO there isn’t anything more boring in Infosec than Access Control – access reviews, entitlement reporting, fire IDs, privileged accounts tracking, wow, those things kill me. But I must say that doing those things properly will probably reduce a lot more risk than buying the last pretty-pizza-box-with-blinking-lights. The problem will be finding smart people who enjoy that enough to that properly.
Today’s biggest challenge in Information Security is to find smart people willing to work with boring stuff.
That’s my last line from my “back to blogging post”. Wow, I’ve just noticed how much I miss doing. Ok, I’m back
This is a information security blog, but it’s also an opportunity to talk about an important cause. Please, take some time to donate (even one dollar) to the victims of the earthquake at Haiti:
RED CROSS: www.redcross.ca
WORLD VISION CANADA: www.worldvision.ca
UNICEF: www.unicef.ca
SALVATION ARMY: www.salvationarmy.ca
MÉDECINS SANS FRONTIÈRES: www.msf.ca
I received an e-mail from (ISC)2 about their new social network website. I tried to use it, but I’ve got the following message:
Sorry, an error has occured.
You must be an (ISC)2 member and have JavaScript enabled in order to access the InterSeC Website.
Please enable JavaScript in your browser, log back into the Member Website, and try again.
OK…is it uncommon to have a security professional browsing with noscript? Thumbs down to (ISC)2…
I’m starting a Wave
on Google Wave to build a collaboration piece on security decision making. Please send
me your contact if you want to participate.
It starts like this:
Security decision making
Dear security friends,
I’m
planning for a long time to work on a paper/presentation about security
decision making. I was planning to talk with different security
professionals to hear about how their decision making process works and
where it can be improved. But I’ve just realized that Google Wave is
the perfect tool for a collaboration job like that. I will, of course,
provide the proper credits to anyone who contributes.
Well, some classification and and taxonomy first. I think we could try to break decision making in:
-
Scope: it can be from a single application to a whole organization. I’m
quite sure that the process changes from one to another, so it makes
sense to consider it.
- Type of decision: what is the goal of the decision? The most common are:
- Trade-offs: the famous control x productivity impact
- Cost: should I take the risk or pay to reduce/eliminate it
- Control Prioritization: among all those security controls, which one should I implement first?
- Risk prioritization: among all those risks, which one should I tackle first?
-
Security optimization: considering all the resources available, how to
deploy them in a way to maximize security (minimize risk)
- Method:
-
Risk measurement: going through the vanilla process of measuring
exposure, impact, threat level, likelihood and getting the resulting
risk.
- Qualitative
- Quantitative: ROSI
- Benchmarking: comparing what others are doing under similar situations
- Regulatory/compliance: doing because it is required
-
Metric based: this triggers the whole discussion about security
metrics, what should be measured, how and what are the desirable values.
- Trends:
-
There are several issues with the risk assessment methodologies. I
don’t like the feeling of “educated guess” from the qualitative
assessments and there are a lot of conceptual failures on theROSI side.
Also, the data available is not good enough to generate good impact and
likelihood numbers. Some researchers believe we should generate new
models to avoid these pitfalls
-
Prescriptive standards: apply more prescriptive regulations, such as
PCI DSS, to reduce the “interpretation” issues from more flexible
frameworks and methodologies.
So,
I’ll add people that I think will bring value to this discussion.
Please feel free to expand the wave. Let’s see where it will take us.
(I’m
also don’t know how to invite some people that I know is testing Wave
but I’m not seeing in my contact list…how do I do it?)
Some interesting references to consider/read about this subject:
http://infosecblog.antonaylward.com/2009/08/03/re-iso-27001-security-re-significant-impact-calculation-in-business/
http://taosecurity.blogspot.com/2006/06/risk-based-security-is-emperors-new.html
http://chuvakin.blogspot.com/2009/09/donn-parkers-risks-of-risk-based.html
http://chuvakin.blogspot.com/2009/09/is-risk-just-too-risky.html
http://www.bloginfosec.com/2009/09/28/classy-data-pt-3-%E2%80%93-ownership-and-risk/
I’m ashamed that my blog has much more of these posts that it should, but yes, this is another one. I’m not posting anything here for some time, life has been a little more demading than usual for other “stuff”. My dog is quite sick (that’s expected for a 17 year old dog, isn’t it?) and almost all “free time” is being spent between taking care of her and doing all “home stuff” that I usually share with my wife, as she is also studying a lot for her college tests. So, once again, I haven’t given up on blogging, it’s just a silent time for now. I’ll be back when things become a little easier on this side.
I was reading the post that I just published when I noted that the post right before that was complaining about attempts to standardize diversity, the curse of the “best practices”. The funny thing is that on the last post I tried to make the case for a big standard, that would probably end up trying to do the same thing I was complaining about on the previous post. Pretty contraditory, isn’t it?
It is, and I’m trying to see how these two different approaches can co-exist. One option, and can see how cool that could become, is to create that big standard as a framework that would allow different implementations of the same process, but all following specifications for inputs and outputs. That would create a big standard with “sub-standard plugins”, suggested implementations for specific processes. Each of those plugins would consider information from those threat modeling components I mentioned before, in a way that you could choose an implementation of a process that is more aligned to your organization profile, technology and characteristics.
That would avoid excessive standardization and also ensure that the basic necessary processes are in place. Now the two posts are not that incompatible anymore and I can go to sleep without that bugging me
I was happy to find Anton Chuvakin’s post about the issues of doing security based on risk management a few days ago. As I said on my twitter, “discussions about decision making (risk based vs. others) is the only thing interesting for me today on the security field”. Anton made a very good summary about why we should consider alternatives to risk management and who else is talking about it.
Honestly, I remember when I first read that 2006 article from Donn Parker that I was somewhat disapointed by his suggestion of doing things based on compliance. It was the old security sin “checklist based security”. All the recent discussions about PCI DSS are great sources of opinions and insights about the subject, and I’m seeing that there’s an overall perception from the security industry that it end up being good for security. Is the checklist based security working?
If PCI DSS is working, it’s certainly not because of those approaching it with a checklist based mind. It is because it is a quite good prescriptive standard. It is clear about what the organizations need to do. But is has limitations.
PCI DSS has a very clear goal, to protect card and cardholder data. The standard allows a quick and dirty approach for those that don’t want to bother with all those requirements. Reducing scope. Think about all those requirements about wireless networks. You have two choices, doing everything required by the standard or removing that network from the scope. With PCI, as long as you can prove that the cardholder data environment is protected, the rest can be hell, it doesn’t matter, you are good to go. Is it wrong? Well, the standard has a clear goal and it makes sense to define the scope around it, but it is kind of naive on assuming that it’s possible to isolate network environments inside the same organization without considering that the payment process (that uses card data) is usually very close to other core business processes. So, PCI DSS is a good standard but it is limited for overall information security purposes.
With this in mind, one could say that creating a “generic PCI DSS” would be the solution for risk-less security. I think it is part of the solution, for sure. The problem is that the scope for that standard is considerably bigger, in a way that it would have to include some less prescriptive requirements. Is there a way of doing that without creating a new ISO27002? Don’t get me wrong, I think ISO27002 is a great standard, but it is so open to interpretation that it can almost any beast can become a certified ISMS. Also, it has on its base the risk management process, that is exactly what we are trying to avoid. The new standard would have to include requirements to solve one of the biggest challenges on information security: prioritization.
Prioritization is the achilles heel of any attempt of doing security without risk management. After all, everybody knows that we cannot protect everything and during the long implementation phases the bigger pains need to be addressed first. How can we do that without using that wizardry to “guess-timate risks”?
My take is that it should be done based on two sources of information: benchmarking and threat modeling. Threat models can be generated based on geographic aspects, organization and business profiles, technology in use. Threats for banks in the same context (same country, for example) are probably very similar. Organizations using the same basic software package on its workstations will share the same threats for that technology too. We should also consider that a lot of the current threats organizations face are pervasive and ubiquotous, they affect almost any organization out there. Except for very few cases, malware issues are a common problem. Sure, the impact from malware issues will be different for each organization, but it seems to me that those characteristics will probably be those considered for many other threats too.
How would an organization “risk-less” work to define its security strategy and the controls to implement? Most important, how it would check its own security status? Is it ok? Should it spend more? What needs to be improved?
That’s where the fun is. And no, I don’t have those answers. But building the processes and tools to do that is definitely the most cool thing to do on this field.
Probably not enough content for a post, but certainly for a tweet
It’s common to see on the security standards, frameworks and best practices a lot of “standard” ways of doing things like access control and patch management. The problem is the organizations are extremely different from each other, not only on the technology but also on processes and culture. It’s pretty hard to suggest a standard process that will interact with so many different components and expect it to work (and perform) in the same way for all implementations.
We should try to avoid standardizing diversity and start selling the basic concepts for each of those processes. Usually, the expected outcome. For Access Control, we should state that the process should provide least privilege, segregation of duties and accountability. For Patch Management, reducing the vulnerability window and “exploitability” of systems.
I’m tired of seeing people struggling to fit “best practice processes” to their organizations (and the other way around) instead of trying to achieve the desirable outcomes. That’s a waste of resources and usually puts security directly against productivity.
When implementing a security process, think about the desired outcome first. You’ll probably find some different ways to get the results, then just get the one that is more aligned to your organization. Remember to document how the new process achieves that, as you probably will not find auditors with this open mind out there. Let they call your process a “compensatory control”, as long as it works and does not make everybody nuts
New Firefox versions will warn you when your Flash plugin is out of date.
This is a cool idea and will help users that are not aware of the need to update software like Flash and Acrobat Reader. I can also see this as the beginning of a trend to centralize the updating of all the crap we run on the client side. Microsoft (and Mozilla, Apple, Google) already have a very good update system for their software. By opening it to other software vendors via a public API, it could be used as a single source of updates. Adobe, instead of deploying its own update system, could simply publish its updates through Windows update system. To avoid non-authorized updates, the user could be asked for the first time if he wants to allow that organization to update its software through the system, with the identity being verified through digital certificates. That would certainly help users to keep their software updates and to reduce the number of agents checking every time if there are updates to be installed. Please guys, let’s simplify this mess.
A was reading this article about AppLocker, the application control system from Microsoft that runs on Windows Server 2008R2 and Windows 7 clients. There seems to be some very good improvements there, specially the “automatic rule creation” part.
In, short, an organization can build its “gold image” desktop, with all necessary apps, and run the automatic rule creator to identify all the applications that will be on the whitelist of things that can run on the desktop. If you are mature enough to have a real good “gold image”, that shouldn’t be very hard to do.
The issue that I can see is with patches and updates. However, the automatic rule creation can work with the Publisher information when the binaries are signed, making it easier to accept new versions for those files. I think I’ll try that in a lab to see how effective that is.
Another interesting thing is that you can enable it in a “Audit only” mode. I have a personal view for whitelist based controls that is deploying them to generate logs only and monitor using a SIEM or similar system. On that way the risk to disrupt the environment is reduced and the exception can be managed on two levels (changing the whitelist, ignoring speficic alerts from the controls). It is one of the best ways to do security without breaking everything and also getting more value from a SIEM deployment. Be aware, however, that the SIEM system alone will not perform any miracles, this concept can only work when you have people and processes in place to deal with the generated alerts and to constantly tune the rules. That’s the price to pay for more flexible security.
