I’m currently re-reading “The Black Swan”, by Nassim Taleb, in a moment when most information security planning and decision-making techniques look like just plain bullshit to me. So, my mood for accepting absolute truths on this fields is becoming even worse than before.
I was reading a post from the “New School of Information Security” blog, which, by the way, is very good. However, there is something from this “new school of thought” that I really have a problem to accept, the idea of measuring the effectiveness of security controls. The post I was referring to includes an example of new techniques to measure and predict the effectiveness of baseball players.
Take, for instance, an affirmation like ”80 percent of the league couldn’t have made that catch”. Thinking on the nice work from Nassim Taleb, people (and so outfielders) physical attributes are usually only slightly different. Checking the past features from league outfielders should not give you enough information to say something like that, specially considering the interval between the games and the constant training for the athletes. It’s too much conclusion based on past data that don’t have a direct causality relation with the event you are trying to predict.
That is also common on security. With the speed of changes and complexity of IT systems, constant changes of user behaviour due to those new systems (social networks?), it is extremely hard to produce a decent forecast of future events based on past data. Why would all the data about the exploitation of OS and web servers vulnerabilities from the past decade be useful to determine exploitation trends of browser vulnerabilities or XSS on social network websites?
We should be a little more skeptical on our ability to forecast events, specially security incidents. The great “new school” I’m waiting to see rising is how to protect our data without relying on magic numbers and formulas. That would be innovation.
I’m surprised that most of the MitB attacks are still just stealing credentials instead of changing transaction contents on the fly. I can see that credentials have an intrinsic value on the “black market”, but the attack model of stealing credentials and then using them to log into the victim account to perform transactions seems too complex for me. Once in the browser, the malware can just change the transaction being performed by the victim, in a way that all the traces (such as IP addresses) would point to his/her computer and not the attacker’s. There’s also no need to transfer the stolen data from one place to another, so it reduces even more the places where the attacker leaves his tracks.
I can see two reasons why they are still not doing that:
- The malware developers are not closely related to the “money criminals” – They are building software to be used by different “clients”, and the best way to implement that portability is to sell credentials only.
- Stealing credentials just work and can be used multiple times, and people just understand the model.
If any of those conditions change, more sophisticated versions of the attack will probably start to detected too. By now, it is important to note that fighting the “stolen credentials” threat doesn’t necessarily mean you are also solving the MitB threat. For that, transaction authentication is necessary.
I don’t hide it from anybody; when doing pentests, my favorite approach was to simply browse information in open shares until I could find some user credentials there (yes, in big organizations, they are always there: scripts, source code, ini files…). With those in hands, try to see what else I was able to have access to; repeat the process until the whole network is owned. No big hack or exploit here, just basic “low hanging fruit detection”.
I just noticed a tool that makes that process thousands of times easier: keimpx.
The description, from Darknet:
keimpx is an open source tool, released under a modified version of Apache License 1.1. It can be used to quickly check for the usefulness of credentials across a network over SMB. Credentials can be:
- Combination of user / plain-text password.
- Combination of user / NTLM hash.
- Combination of user / NTLM logon session token.
If any valid credentials has been discovered across the network after its attack phase, the user is asked to choose which host to connect to and which valid credentials to use, then he will be prompted with an interactive SMB shell where the user can:
- Spawn an interactive command prompt.
- Navigate through the remote SMB shares: list, upload, download files, create, remove files, etc.
- Deploy and undeploy his own service, for instance, a backdoor listening on a TCP port for incoming connections.
- List users details, domains and password policy.
Two posts in a day…I’m probably sick or something like that 
I was reading an interesting article by Bill Brenner on CSO Online, “Five Security Missteps Made in the Name of Compliance”. Although I don’t disagree with what is listed as missteps (in fact I think they are quite correct), something in the last paragraph caught my eye:
“The best advice against all these missteps, experts said, is to simply slow down and take careful stock of where the company’s greatest risks are. From there, companies need to take careful study of the security tools available to them and figure out before buying them if compatibility with the rest of the network will be an issue.”
Sure, it is THAT easy! Honestly, he just listed some of the hardest things to do in security. Ok, he is not saying that it’s easy, but c’mon! Can you really say that in your business environment you have the option to “simply slow down”? i would love to, but that’s something that is not always possible to do. just like checking “where the company’s greatest risks are”. This one is huge. And I must say that my perception about organization-wide risk assessments is ETI - Expensive, Time consuming and Ineffective. So, you’ll have an idea of where those big risks are coming from, not a “careful stock of”. There’s too much uncertainty ou there and it’s better to live knowing that there’s a lot of things you don’t know instead of dying trying to figure them out.
You can conduct careful studies of the tools available, but the “corporate truth” is that in a lot of occasions you will simply work to deploy something that someone else bought or will have to deal with things that are not best of breed because they were part of a bigger deal/suite or simply cheaper. Finally, on checking compatibility with your network before buying, you’ll only succeed 100% on that if you run a PoC in your entire environment…I mean, almost never. You’ll have to deal with surprises during the implementation. Yes, you can avoid buying Unix stuff to run on Windows boxes, but in big organizations the number of combinations of hardware, OS, middleware, applications AND bizarre settings is incredibly high. Be prepared to deal with those surprises.
The point is, Bill is right about the mistakes, but I think he is to optimistic about how to prevent them. Some of them are simply what we need to pay for working in this crazy field. Looking back they will look like mistakes, but most of the times we simply cannot do anything better than that. As I like to say, “it’s acceptable to do stupid things, as longs as it is not for stupid reasons”.
OK, I’m trying to get out of from a long hiatus of producing content by putting together a presentation about Log Management: the devil is on the details. I have been working in log management projects for some years by now and I noticed I managed to assemble a nice list of small issues that you find when working on those projects that will normally be responsible for 80% of the headaches. As I’m saying in the presentation, things that the vendors simply don’t know how to solve, so they never talk about it
Some of the things I’m including there:
- Windows log collection: the options, the issues with them
- Credentials (user IDs) management when doing file transfers and connection to DBs
- Systems inventory (who are my log sources?)
- Privileges needed to collect logs (DBA rights to get logs???)
- Purging logs from the sources (who’s gonna do it?)
- and some other stuff
So, if you have an interesting experience on implementing log management systems, please let me know those interesting “details” you had found during the process that caused you problems. It will be interesting to talk about the subject without going into the old “performance / parsing / reporting” discussions. Most of the vendors have figured out how to solve those problems. I want to talk about small things that hurt and still haven’t been solved.
Hope to get that ready for a TASK meeting or something like that. If I get enough feedback and input, it may grow up to a SecTor or similar submission.
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.
