Information Security, Homeland Security, and finding someone to pin it on

In the recent spree of cyber attacks on a plethora of US and international government and federal related establishments a lot of speculations are being thrown around as authorities are trying to find the threat community behind it.

As computer systems are reigning most of the control over our daily lives – from transportation, through financial systems, and up to government facilities that provide research, analysis and even critical infrastructure to support what we know of now as “modern life”, attackers find it easier and easier to poke at such systems as their security is left mostly as an afterthought. Most of the focus when the relevant organizations approach the forensics and remediation of such breaches is first to recover any lost data, and then to identify not the root cause of the breach, but the attacker.

As the blame game runs amok, the actual privacy and confidentiality of the core (digital) elements of our modern society are left for grabs. When groups such as LulzSec, Anonymous, and any other book-reading internet-browsing anonymous-under-several-proxies infosec-warrior find it as easy as running a few scripted tools on their target list to find easy to exploit issues, we are facing a very tough job of figuring out who to blame.

Nevertheless, blame by itself (or attribution as we like to refer to it in the more politically-correct industry circles) won’t help us in mitigating such attacks. It may be helpful for organizations to have someone to pin the “adversary” tag on – especially when dealing with defense/government/federal institutions who’s budgets can be manipulated more easily under the threat of a foreign nation. But when looking at the ability to actually come up with evidence to support such claims we often face empty hands, and a thick smokescreen of assumptions, prejudice, and incompetence.

On the other hand, when viewed from a strategic/political stance, it can be easily seen how a string of breaches in facilities that share a common ground (such as the one presented by Rafal Los of HP in his great article “DOE Network Under Siege”) can be attributed more to a nation state than to a fun-seeking internet-bored group.

This simple reality – of having intricate connections that are often only visible when looking at the bigger picture of security incidents, allows state sponsored attacks to happen without much scrutiny or the ability to thwart them on a more strategic position.

The bottom line remains the same – chasing after excuses and online enemies won’t get us to a more secure state. Investing in proper education, training, exercises, people and (lastly) technologies, will. Instead of trying to investigate breaches from an attribution standpoint, we should be investigating root causes to the deepest level (i.e. not stopping at “a 0-day vulnerability we didn’t know of”, or the bit-bucket of “It’s an APT”) that involves how we manage our electronic infrastructure and how we keep track of what’s going on in it after the initial setup is complete and the contractors/integrators pack up their people and leave.

Post Brucon thoughts – guesstimates in an engineering field

So, another epic Brucon has ended, and while everyone is getting their thoughts together again (the amount of super smart people I have had the pleasure to have conversations with is unimaginable), I wanted to post a quick recap.

First things first – numbers. I’ve been working with the FAIR methodology quite a while now, and have actually (with the kind permission of Jack Jones) integrated some of its elements into the Penetration Testing Execution Standard (PTES). Watching the discussions that started after Jack’s talk at Brucon was heartwarming. Pentesters and security practitioners finally “get it”, was divine. Working in a field of engineering that has the least engineering in the sense of how it’s applied to businesses has been frustrating to say the least. With the ability to effortlessly connect the technical elements of vulnerabilities and exploits to business-speak has been one of my personal challenges (and hopefully strengths), and being able to tilt the industry even a little towards that direction is something that we all needed for a long time.

A quick “teaser” to add on top of it (which has been previewed in my talk) is the ability to also marry in the social media risk into the risk management practice (look out for some more cool research and insights coming from that direction very soon!).

Which leads me to the last point – the ever evolving presentation I use to deliver the message about data exfiltration is provided for your viewing pleasure. Don’t fear the >100 slide count – it’s mostly the “build” effects that I left in for clarity.

Looking forward for some more discussions and developments in the way that we as an industry are justifying what we practice (if it wasn’t obvious by now – go check out what FAIR is, and then start thinking on how to integrate it into what you do…).

Career in Information Security

So, here comes the time when I say out loud something about where I work on this blog… My company – Security Art, is at the challenging phase where we are growing rapidly, and as a result are also looking to grow our excellent team.

If you ever ran a small company you know how hard this phase is. Making sure not to outgrow the amount of work you can take, making sure you can still deliver the top-notch services you got your customers used to (and what built your reputation in the first place), managing the growth, having people trained and lined up to the way you do business, the list goes on and on…

Bottom line, It’s one of the more exciting (and scary) phases that a boutique company such as ours goes through, and we are looking for more talents to join our team.

Beyond the “standard” job descriptions you can find on the careers page on our company website, I can only say that:

  1. We work hard. Probably harder than you have worked before. Ask around and people who know us can tell you.
  2. We love what we do. See 1. If we wouldn’t have, we would have burnet out years ago. This is our passion, this is our hobby, and this is what we are good at.
  3. We are all n00bs. Anyone who thinks they are an expert at something and therefore have reached some faux pinnacle of their career is probably not in InfoSec. We learn new things every day. We research new technologies, law systems, politics, people, societies, companies, business, finance and other areas on an ongoing basis. The landscape keeps changing and our job it not only to stay on top of everything, it’s also to plan ahead, and try to predict what’s going to be the next challenge. By definition, 80% of what we look into will not be relevant. It’s the 20% that does that makes it later to presentations in security conferences…

Now that you got a little taste from the “behind the scenes” of what we are looking for, and think you can step up to the plate – please do!

Looking forward to see some new blood whom we can all learn from a few more things and share our passion with.

P.S. No I didn’t forget 4 (and people who know me can attest to the fact that there is a no. 4) – party hard. Just as you need to kick-ass in your work, you are allowedrequired to party just as hard ;-)

What the * is wrong with mobile security

Long time no post. Sorry about that <insert favorite excuse>.

Anyway, as you can probably imagine, here’s another rant brewing. We have been dealing with a barrage of mobile application security issues lately, and although I had the feeling that there was a lot wrong with the industry back there I haven’t realized it was that bad.

I mean – it’s supposedly almost the same developers, right? Some Java, Objective C, a little JS/Json/GUI/, the concepts are still the same. Oh, was I wrong. When testing some of these applications, and looking at how they are (much easier BTW that with “traditional” software), it almost seems like we are blinded by the fancy little gadget we got sitting on our desk waiting to be tested, and just push out really crappy code with no apparent attention to how it works, how secure it is, or how does it reflect on the security of the rest of the bank/commerce/corporate security.

Forget all the shortcuts that completely bypass any reasonable process and procedure that are implemented through the “regular” (i.e. web, web services, even client-server) interfaces, and the fact that web services are created to support that.

Forget that authentication is almost thrown out the window when you used to have multiple factor authentication on other channels.

Go back to basics. Ummmm, like, SSL? It has been too many times that you see an “application” that is no more than that hybrid thing Apple allowed developers to do – a few HTML pages that get rendered really nicely on an iDevice, some jQuery and CSS tricks, and maybe even bother through churning the end result through PhoneGap to be like the cool kids with the native apps. Problem is – developers go full retard on shiny things like this. The completely forget the fact that the user’s phone is just like a PC, and is going to be connected to so many non-trusted wireless networks that it’s not even funny to think how much data will be exposed through their insecure plaintext calls.

One thing that really helps developers stay in full retard mode is the lack of any security indication on the device that their communications are done completely in the clear. No bright yellow/red/green padlock that indicates an SSL connection, no API checks to verify that some crypto library is in use if any of the “sensitive” (read: contacts, network access, mail, locally saved data, etc…) is accessed by the application. Nothing.

That’s how we got to a point that sensitive data is leisurely sent unencrypted over non-trusted WiFi connections, along with almost everything you can think of from the phone (GPS coordinates, user information, you name it). That’s how we got to a point where useless web services are opened up (again – no requirement for an SSL connection) on financial/corporate/commercial servers to allow logical shortcuts just because the mobile applications needs to be “streamlined”.

We need to put our foot down and say “no more”. We need both the big guys (Apple, Google, Microsoft, RIM) to have a real certification and testing program for their *Stores that actually look at what the application is doing. We need more logic and more process in the way that applications get developed and commissioned. We need developers to get off the “I need to be at the *Store” mentality, and think like they used to in the sense of “we are going to get so pwned if I put this application out like this”. We need product managers and marketing departments to think if they want to be the next Sony™ getting nailed 21 times in a row and still not realizing they are so far behind they need to take everything offline and start getting their stuff together.

We just need to pull our heads out of the sand and smell the napalm. It’s a war out there, and your shiny device doesn’t give a small rodent’s rear-end about your security as long as it looks good.

Rant off, maybe one more post before Vegas. See you all there!

How great perimeter defenses are hurting you

I have looked for a good example for a real-world security practice that is misconceived and that also applies to information security. Recently I have had a chance to read an opinion article that talks about physical security measures that are put in to protect small populations (read army bases, gated communities, etc…) and how many of the “traditional” security thinking is actually hurting them.
The example that was cited, talked specifically about building fences around such facilities, and their actual and perceived effect.
The real effect of such a “security” fence is very low. These fences can be easily bypassed with very basic skills and tools.
However, the perceived effect of such fences is incredible. On one hand, the protected population sees that there is a fence that goes around the entire perimeter, and immediately think “cool! we are well protected”. They can SEE the perimeter, and it has an immediate effect on how the area is perceived (especially in gated communities).
On the other hand, a much more worrisome element is how such fences affect the way that the security personnel behave. One would think that security professionals understand that fences are no more than a slight delay for an attacker that looks to break into the protected area. Nevertheless, the article talks about how security personnel are actually putting their guard down when assigned to work in fenced areas. It talks about how the perimeter (again – being highly visible and seemingly intimidating) provides some comfort to the guards, and makes them prone to focus on the gates and openings. Whereas guards that were put in duty to protect non-fenced compounds were much more vigilant in identifying tactical areas that would be used to watch the compound, and to attack it. They have been more active in their movements across the protected area, paying attention not only to the access paths used daily, but to all aspects of the area.

Now think about everything that I have discussed above in information security terms. We have been having firewalls blinding our CIOs, IT personnel and purchasing managers. The ability to market a product that specifically opens access paths into the organization so successfully have actually degraded the security posture of most organizations. Think about it – one of the things that come up very early in a conversation about an organization’s security protections will usually be a firewall.
The more problematic aspect here – much like in the physical fence example, is that firewalls make security personnel put their guards down. They fail to be vigilant in identifying access paths, data patterns, and potential pitfalls in the way that the organization keeps, processes and uses its information.
Don’t get me wrong – I’m not a huge “de-perimeterization” fan, but we do need to take note from this way of thinking about security. Everyone is preaching about “layered security”, but keep putting a lot of focus on the perimeter defenses while leaving the internal layers mostly unprotected.

In summary – when you think about how your organization is protected for security breaches, remember the “fence effect”. Remember how people that live in gated communities have a wrong sense of protection, and how guards stationed at checkpoints and gates are usually focused on the opening rather than the fence around them.