Security Balance

Mainframe security

2013-01-24T10:45:00.000-05:00

Still don’t understand why (or don’t believe) the security of apps that interface with old mainframe applications is none or just security by obscurity?

Here’s the level of understanding of networks of the average mainframe guy:

http://www.mainframegurukul.com/ibmmainframeforums/TSO-Command-retrive-Server-name-from-IP-Add-post5539.html

(via @mainframed767)

There’s a huge knowledge gap between mainframe and network/distributed systems guys. The mainframe guys don’t even understand the threat models from our systems (most of them don’t understand anyone can connect to an open port on an IP host, for example), and we don’t understand how things work inside big iron. I’ve been talking about this for years, it’s a recipe for disaster.

I wonder when we’ll see the first malware capable of probing those systems.

They are certainly shifting!

2013-01-17T13:01:00.000-05:00

Loved that bog post from Jeremiah Grossman!

“the bad guys SHIFTED”

They’ve been doing that for a long time (here’s my post about it, from 2006), and it’s economics 101: they’ll always be looking for the path of least resistance and for higher pwn/effort ratio. I wrote about it again a few months ago.

Jeremiah insight about security tools is right on the spot. Does anyone remember some nice work from the Sensepost guys around XSS code created to be triggered on web interfaces of security tools, such as IDS and SIEM? That was a long time ago, but it confirms the feasibility of what Jeremiah is saying.

An indirect effect of it is how hard it becomes for us to run appropriate Risk Management programs. Some completely disregarded targets and threat vectors can become mainstream in just a few months, basically invalidating models and assumptions. As most risk assessment methodologies require you to map the threat vectors being considered, it’s hard to get reliable results when they are constantly changing. How to handle that?

A good option is to try to decompose the model as much as possible in smaller components, isolating the pieces that are always changing in a way that you can control how that uncertainty affects your model. FAIR is a good example about how to do that, as VERIS is a good way to make past data more usable even if it’s related to incidents occurred under a different reality. With those decomposing models it’s possible to identify the pieces of data we have with less uncertainty and leverage that to identify sources of risk and opportunities to reduce it. What does it mean? It means that vulnerabilities being exploited change all the time, initial compromise points too, but the actors are more or less the same (I mean, the change in the threat agent profile is slower than the other components) and they are usually trying to accomplish the same thing by reaching the same end targets. By knowing those pieces we can identify control opportunities that will affect less uncertain and less dynamic aspects of our risk, allowing us to get a more reliable and measurable result.

bolt on vs. built in

2013-01-11T14:39:00.000-05:00

So, for a Friday the Twitterverse has been quite busy with interesting security discussions. Mostly generated by Gunnar Peterson (@oneraindrop) and Rafal Los (@Wh1t3Rabbit), the discussions are floating around why others (business, developers) are not listening to security. As part of the discussion, the old absolute truth “security must be built in, not bolt on” was repeated over and over again. Of course, isn’t it obvious?

Is it?

Shouldn’t we’ve been trying to think out of the box, to question even the “absolute truths”? (That’s for @joshcorman)

So, can’t we stop and think for a while why we think security should be built in, and not bolt on? And why, even if everyone agrees with it, we are still bolting it on, over and over again?

Well, I think one of the things we should be doing is thinking about new and better ways to bolt on security! If it’s happening it’s certainly because the business wants to work this way. Ok, in ideal conditions we may never be able to achieve the same security level with it (or optimize the security/cost ratio), but if that’s the way all the other players involved want to deal with security, shouldn’t we try to optimize how to do this?

It’s just a small firestarter as I haven’t thought that through, but I think we can, in fact, do something like that. Just think about all the things that are being done based on the new virtualization technologies. Things like Fire Eye, commonIT virtual browser technology and other sandboxing products, they are all “bolt on” security. I can remember a couple of situations I dealt in the past where the best security solution found for a specific system was to encapsulate it in a security shell, something that is extremely easy to do with the current virtualization tools.

So, instead of trying to change the world, why can’t we also spend a few minutes thinking about how to improve the current “bolt security on” approaches? It may reveal being a better option than the pie in the sky we keep praising in this small and cozy echo chamber called security industry.

Great study on spear-phishing from TrendMicro

2012-11-29T10:54:00.000-05:00

Trend Micro has published a great study about spear-phishing email. It’s available here.

Although I would also like to know the overall numbers (i.e. amount of samples that were used during the research, to ensure the findings are really meaningful), there is good data in the paper that can feed into a well established SecOps practice. Some interesting pieces:

“Monitoring revealed that 94% of targeted emails use malicious file attachments while the rest use alternative methods like installing malware by luring victims to click malicious links and to download malicious files and using webmail exploits”

“Spear-phishing emails can have attachments of varying file types. We found that the most commonly used and shared file types in organizations (e.g., .XLS, .PDF, .DOC, .DOCX, and .HWP) accounted for 70% of the total number of spear-phishing email attachments during our monitoring.”

I’ve been spending a lot of time looking at numbers that affect the ability to look for potential compromises. For example, how many email messages an organization usually receives (of course it varies a lot according to size/business)? How many of those have attachments? How many of those attachments could be considered potentially dangerous? Is this information useful to help on narrowing the focus of detection/investigation practices?

I believe our industry has spent a lot of time working on detection systems without necessarily leveraging evidence based guidance about what to look for, where to look for. Reports like this one from TrendMicro are really useful to change that and help organizations to maximize the return of their SecOps resources.

The grain of salt

2012-11-14T14:48:00.000-05:00

As a non-native English speaker, I always like to learn new idiomatic expressions that give color to the language. One of my favorites is to tell someone to take some information “with a grain of salt”. According to Wikipedia,

The phrase comes from Pliny the Elder's Naturalis Historia, regarding the discovery of a recipe for an antidote to a poison.^[2] In the antidote, one of the ingredients was a grain of salt. Threats involving the poison were thus to be taken "with a grain of salt," and therefore less seriously.

An alternative account says that the Roman general Pompey believed he could make himself immune to poison by ingesting small amounts of various poisons, and he took this treatment with a grain of salt to help him swallow the poison. In this version, the salt is not the antidote. It was taken merely to assist in swallowing the poison.

The Latin word salis means both "salt" and "wit," so that the Latin phrase "cum grano salis" could be translated as both "with a grain of salt" and "with a grain (small amount) of wit."

The phrase cum grano salis is not what Pliny wrote. It is constructed according to the grammar of modern European languages rather than Classical Latin. Pliny's actual words were addito salis grano.^[3]

But why am I talking about this in a Information Security blog? Because I want to say that all security advice should be taken with a grain of salt!

When I’m reading security blogs and listening to security podcasts I’m always impressed how some of my colleagues present some advice as the ultimate truth. There are a lot of “MUSTs” (in fact, a lot of “MUST NOTs”), as a magical set of rules that will allow us to easily do everything we want in a secure manner. However, all of them forget about one of the most important pieces of solution design exercises: CONSTRAINTS.

Of course we don’t want to use FTP or TELNET. Yes, 4 digit only passwords is stupid. Oh, how come you still have Java installed?

It’s not because people are stupid (well…ok, sometimes). It’s because they have, in most cases, valid constraints to be considered when security is being assessed or designed. Sometimes the only software available in the market for a specific business process is that crappy screen scraper based on TELNET. Or that hardcoded password crap is provided by the vendor of a multi-million dollars medical device that you can’t just throw away because of a security vulnerability. We should always try to apply pressure and make people aware of how security unwise those things are, but let’s be honest, if we were in the place of an executive, would you really consider a huge change to your business because of things like that? No, you would tell your security team to “be creative” or, most probably, call one of those big brand consultants to tell you what you want to hear.

So, let’s pick our battles. We’ll never be able to work under ideal conditions. We’ll have to deal with “stupid” things like FTP, Telnet, unpatched Windows boxes and unsupported software. We should keep evangelizing the IT world that security should be built-in, but we have to be prepared to bolt-on.

Next time a security curmudgeon comes with his canned “you MUST NOT” advice, ask him back: “and what if I have to?”. That’s a good way to see who is just playing to the crowd and who deals with real world, full of constraints conditions.

Groupthinking

2012-10-17T14:00:00.000-04:00

Very nice post from Dave Shackleford:

These days, I am very, very afraid for the future of CISOs. Over the past few years, and specifically the past 12 months, I have become increasingly alarmed at the level of “groupthink” and “synchronized nodding” going on with security executives. Here are some of the things I am seeing:

1. Lots of talking about the same shit, with absolutely no innovation at all. Good examples include metrics (we need them! they’re IMPORTANT!) and talk about policy and governance that usually means absolutely nothing.

2. A desperate need to find “the metrics” to report to “senior management” – there is no such thing. Your management, in all likelihood, does not want any tactical numbers on antivirus events, IDS alerts, or such blather. They want real risk advice on business goals and functions. Period.

3. Managing by managing what everyone else is managing. You would not BELIEVE how many security products get purchased because other security executives are buying them.

[…]

That’s really the current picture of our field: people doing what the others are doing. I like his idea of treating the security program like a startup, but an interesting thing to consider is how many CISOs would have the opportunity to do that. Their bosses would expect something different, their peers, security committees and external consultants/auditors. It’s not easy to escape that rat wheel!

A CISO job where one have the opportunity to shake things up like Dave suggests is a dream opportunity for any security professional. Unfortunately a lot of those in positions like that are too busy…groupthinking J

This is a test post

2012-09-20T10:11:00.000-04:00

Sorry about this, but Posterous put some odd stuff on my LinkedIn profile for my last post's "autopost" feature. investigating what's going on...

Best of breed

2012-09-19T15:58:00.000-04:00

The debate about whether it makes sense to buy best of breed products for security or if “good enough” is good enough (Ok, that was ugly J). Mike Rothman wrote a very good post about this a few years ago. I agree with most of his point on this, that “best of breed” makes sense for innovative products but not for mature technologies. But lately I’ve been seeing some discussion that expands the discussion.

I think that Mike’s post makes all sense for products. However, I’ve been seeing the same rationale being applied to services. But I’m really not sure that the same thing applies to services. Let’s think about Managed Security Services, for example. If you are outsourcing your SOC, even if it’s a mature service offering in the market, does it make sense to go for the “good enough”? Doesn’t look like it does. For mature products there isn’t a big difference between the best products and rest of the pack. In addition to that, there are usually benefits to get a product that is part of a suite you already have in place, from a vendor that you already have an enterprise license agreement or provides better integration with your other tools. But services are about human intelligence. You get what you pay, plain and simple. You can have you big box IT services provider doing that, but if you look the way they operate you’ll always see the same things: high turnover, low salaries, unskilled and inexperienced employees. It’s just not possible to provide the same level of service as the boutique providers that are specialized in that type of service and thus put a lot more energy on getting the right people doing it. The features of a service are directly linked to the people providing it, so the differences between the best and rest are higher than for products.

There are services where that wouldn’t matter, where you really don’t need intelligence and content, just a bunch of eyes and hands. Those are the services that are usually outsourced in all other disciplines, and I don’t see why it wouldn’t be different in IT or Infosec. But we often underestimate the skills necessary for some services, and MSS are usually the case. A SOC manned by unprepared analysts will only spit alerts provided by default configuration and out of the box rules from standard tools. A best of breed SOC will bring intelligence to the work, providing customized rules, configurations, threat information, ingest internal context information and prove meaningful alerts. Be careful when discarding the best of breed. For things like highly specialized services the “best” is the minimum you should expect, and “good enough” will almost always be “not enough”.

What should I do about BYOD?

2012-09-14T14:15:00.000-04:00

There are lots of people providing canned advice about BYOD (for all the cloud related stuff too). It’s very important to understand that the only correct answer for the “what should I do about BYOD” question is the standard lawyer line: it depends.

Technology trends (I don’t question the fact that it is indeed a trend) such as BYOD often bring advice in the form of “you can’t fight the future” and “security is past the time of blocking new stuff”. I definitely agree that anyone working with security should keep an open mind, specially for technology trends. But those that are always anxious to stay on the bleeding edge should also understand that security must consider multiple factors when making decisions. BYOD is a very good example for that.

How prepared is the organization for BYOD? What’s the maturity and technology state of the organization network? About the applications, are they prepared to be used in a BYOD way? What’s the point of allowing people to work on their iPads if most of them use to work on fat client applications running on Windows? What about access control, encryption, etc? Is your network prepared to handle those for those devices?

Technology is only one aspect. Of course it’s easier to people to read email on only one nice smartphone. But are there any compliance regulations that should be considered? Financial Institutions usually have to comply with a lot of regulations regarding monitoring and controlling employee communications, how will they enforce those in a BYOD model?

It may be straightforward to decide about BYOD in a startup in California, but a big defense supplier may have a few additional threats to consider when deciding about that. Keep that in mind when someone asks for advice on BYOD and any other technology trend. The answer may not be as simple as you would expect.

DLP and encryption

2012-09-10T12:53:00.000-04:00

The “Security Manager’s Journal” series of articles from Network World are a really nice way to understand the day to day challenges of real Infosec shops out there. Today’s article, “DLP tool is suddenly blind to email”, is a very interesting example of the challenges related to DLP and encryption. However, the most interesting aspect of Today’s article for me is the approach around decision making for the issue reported.

Summarizing the post, the author says they had implemented a DLP solution, but recently it stopped finding data leaving by email. It was found that the issue was caused by opportunistic TLS encryption between their Exchange server and the cloud based anti-spam solution. After finding that the author goes about the potential solutions to allow the DLP system to inspect the encrypted traffic.

What I found interesting about the article is that he never mentioned the alternative to disable encryption. WHAT?? ARE YOU FREAKING NUTS?? Yes, I’m serious. I mean, encryption is always good, but let’s consider it; email hitting the anti-spam provider will probably be delivered to the final destination unencrypted. So, what’s the real benefit of encrypting it between their Exchange server and the anti-spam system? Is it more valuable than the ability to scan (and block?) the outbound messages for data leakage?

That was something that I’d like to see when issues like the one described are discussed. We know that security is always about trade-offs, and this case is about a slightly different trade-off: one control for another. How would we compare the value of the controls? What’s the organization priority on this case? Those are all questions that would help understanding the scenario and adding a more mature risk management spin to the whole thing.

Elderwood project: the FUD, and some reality too

2012-09-10T12:25:00.000-04:00

It’s been interesting to read all the frenzy about what Symantec has been calling “The Elderwood Project”. The summary is “we are seeing these guys, who were behind that Aurora thing some time ago, still using a lot of 0-days in their hacking of NGOs, defense supply chain and government agencies”.

There are many different spins around the story now on the interwebs. There any many degrees of FUD around it too, but it’s important to analyze and thing about it carefully. Take, for example, this piece from Symantec’s blog post:

In order to discover these vulnerabilities, a large undertaking would be required by the attackers to thoroughly reverse-engineer the compiled applications. This effort would be substantially reduced if they had access to source code. The group seemingly has an unlimited supply of zero-day vulnerabilities. The vulnerabilities are used as needed, often within close succession of each other if exposure of the currently used vulnerability is imminent.

I’m not here to downplay the efforts of finding new 0-days. I cannot do it with my technical skills, I know it’s something really hardcore. But wait a minute, “a large undertaking to thoroughly reverse-engineer the compiled applications”, with supposed access to source code? My skeptical alarm rings loud here; we know a lot of security researchers that have been founding dozens of vulnerabilities in the same applications without access to source code and, if not with “minimum effort”, just by playing with fuzzers and doing some part-time (sometimes just for fun) testing. While I think there are really very good people putting some decent effort on finding vulnerabilities, I don’t think we can conclude there is a huge lab with never ending resources too. It might be, but we just don’t know.

Now, there’s something important to take as lessons learned from this. It is the fact that patching is just not enough, and that you have to have good defense in depth and detection capabilities in place too. If the adversary has some “unfair” advantage, such as 0-days, we need to level the field by boosting our monitoring capabilities. It’s important for “regular” organizations, but extremely important for those that can be an interesting target for motivated attackers (state sponsored, crime rings, carders, etc). This is not FUD, guys. It’s reality.

Security generalists (and QSAs...)

2012-08-29T13:31:00.000-04:00

This post is not supposed to be a rant about PCI DSS and the quite common low-qualified QSAs that make hell of the life of those pursuing compliance validation. Although it evolved from that, it’s now just an understanding from my part about the role of generalists in Information Security.

They are the glue. But more about that later.

I’ve been working through a PCI validation assessment and during a discussion of findings with the QSA I realized that, in a room full of people (and more than one QSA), no one was really understanding the requirements that were being discussed, their intent and what would be the alternatives that could be acceptable as compensating controls. It was all around custom applications development, so requirements 6.3 to 6.6.

PCI DSS includes a bunch of requirements for secure development of custom applications. There are items for adding security considerations in the early phases of development, doing code review, security functionality testing and vulnerability scanning (not mentioning secure coding itself). My personal point of view is that it’s too prescriptive (a recurring criticism about PCI DSS), where maybe the best thing to have would be some outcome based requirements. After all, what we want are secure applications. Or a better description, applications that can’t be exploited for unauthorized access to cardholder data.

An issue with all the prescriptive requirements is that they force people involved to understand a SDLC. They need to understand exactly what is a code review, functionality testing and vulnerability scanning. Without that you’ll see discussions where those definitions are used interchangeably and just make the assessment messy. If the QSA is one of those who can’t understand the differences, it gets VERY messy. Is that because he is a bad QSA? Yes, from a blunt point of view, as the QSA should be able to understand what he needs to check, but I think we are not being entirely fair with those professionals.

What’s the required background for a QSA? If it’s a guy who used to work with Network Security, then went through the QSA training and passed the exam, is he ready for any assessment? Unless he is one of those curious and ever-learning minds, it’s not a shock if we find he (and other auditors and security professionals in general) is completely ignorant in big pieces of the body of knowledge (BOK) required by his function. How can that happen?

One of the key answers is how security professionals obtain their credentials. Different than engineers, lawyers and doctors, we are not required to get a degree in Infosec and sit for a board/college exam. It’s no different than many IT related jobs, but there’s a catch. We are simultaneously asking people to have a minimum level of knowledge in a number of disciplines and not requiring them to prove that they achieved that.

But what about the certifications? CISSP? The QSA test?

All of them will (at least in theory) cover everything, but will gladly allow someone to pass without a clue about pieces of the BOK. There’s a minimum pass mark, but in almost all those credentials exams there is no minimum mark per knowledge domain. So, you can ace the network security piece and go blank the secure development part, and it’s still ok. The obtained credential, however, still implies that you have that minimum skill level in that domain you couldn’t answer a single question.

I’ve seen that multiple times. CISSPs that couldn’t even understand firewall rules or don’t know what an application vulnerability looks like. It is the same thing in the QSA training, so you’ll end up with someone that needs to assess if an organization is doing security functionality testing but doesn’t even understand how that is different from code reviews.

Civil Engineers, for example, can’t become engineers if they can’t achieve a pass mark in Solid Mechanics. Having to sit through (and pass with a minimum mark on) individual courses that compose the Engineering BOK ensures that no critical gap will exist in an engineer formation. It’s not perfect, of course, but it’s far better that the unrealistic assumptions of minimum skills we currently have in Infosec.

That’s where the Infosec generalist comes to the stage. There are several roles in our field that must be filled with people with minimum skills in each piece of our BOK. QSAs are just one example. If we want to get rid of those “how can he ask something so stupid” moments (ok, reduce…there’s no patch for stupid), we must start forcing people in (or trying to get in) those roles to reach minimum levels on all BOK domains. Let’s change the CISSP credential (or create a new one), for example, forcing the candidate to reach a minimum score on all domains. Same thing for QSAs, CISAs, etc. I’m not sure if I want to advocate the creation of a new certification, but I’m starting to think that it could be useful too. Reducing the pressure for early specialization is also something that we could do to increase the number of good generalists out there.

There are many roles out there that would benefit from good quality generalists. Security organizations within big enterprises normally have consultants or advisors lined with the different LOBs or departments, with attributions that go from access control responsibilities to providing security requirements to new applications and business processes. I’ve met lots of people in those roles, but only a few had the necessary skills set for that.

The interesting aspect of those roles is that they share a common thread: they are often a liaison role, bringing together different groups with their specialists. Without a generalist the dialogue with one or more of those groups is undermined, with that person usually lining up with the group more aligned to his skill set and being seen as “one of them” by the others. Think about it. Developers x Infrastructure, Policy x Technology, Business x Technology, Servers x Networks, Blue Team x Red Team. If there’s someone capable of speaking the language of all those groups he’ll be able to reduce conflict, acting as “the glue” between them.

There is value in having security generalists. Keep that in mind when hiring people for those roles, or when considering your career options. Even if your plan is to eventually manage a team of security professionals, being a generalist puts you in an advantage position for that (but don’t forget that “Manager” is also a role that has its own set of minimum skills).

Weaknesses in MS-CHAPv2 authentication - From MS Security RD blog

2012-08-21T12:50:00.000-04:00

Interesting post from MS Security Research & Defense blog describing the newly discovered MS-CHAPv2 weaknesses:

MS-CHAP is the Microsoft version of the Challenge-Handshake Authentication Protocol and is described in RFC2759. A recent presentation by Moxie Marlinspike [1] has revealed a breakthrough which reduces the security of MS-CHAPv2 to a single DES encryption (2^56) regardless of the password length. Today, we published Security Advisory 2743314 with recommendations to mitigate the effects of this issue.

Any potential attack would require a man in the middle situation in which a third party can get all the traffic between the client and authenticator during the authentication.

Without going into much detail about the MS-CHAPv2 protocol, we will just discuss the part that would be affected by this type of attack: the challenge and response authentication. This is how the client responds to the challenge sent by the authenticator:

The authenticator sends a 16 byte challenge: CS

The client generates a 16 byte challenge: CC

The client hash the authenticator challenge, client challenge, username and create an 8 byte block: C

The client uses the MD4 algorithm to hash the password: H

The clients pad H with 5 null byte to obtain a block of 21 bytes and breaks it into 3 DES keys: K1,K2,K3.

The client encrypts the block C with each one of K1,K2 and K3 to create the response: R.

The client send back R,C and the username.

Or:

C=SHA1(CS,CC,UNAME)

P=MD4(PASSWORD)

K1|K2|K3=P|5 byte of 0

R=DES(K1,C)|DES(K2,C)|DES(K3,C)

There are several issues in this algorithm that combined together can result in the success of this type of attack.

First, all elements of the challenge and response beside the MD4 of the password are sent in clear over the wire or could be easily calculated from items that are sent over the wire. This means that for a man in the middle attacker, the gain of the password hash will be enough to re-authenticate.

Secondly, the key derivation is particularly weak. Padding with 5 bytes of zero means that the last DES key has only a key space of 2^16.

Lastly, the same plaintext is encrypted with K1 and K2, which means a single key search of 2^56 is enough to break both K1 and K2.

Once the attacker has K1, K2 and K3 he has the MD4 of the password which is enough to re-authenticate.

- Ali Rahbar, MSRC Engineering

Now, about that “Any potential attack would require a man in the middle situation in which a third party can get all the traffic between the client and authenticator during the authentication.” – Isn’t that exactly the scenario that a secure authentication protocol is supposed to protect you against?

A quick tale about a PMT

2012-08-17T17:50:00.000-04:00

After my last post about PMTs I remembered one situation (in a previous and distant life) when I worked for a financial institution security office. We were being hammered by Internal Audit about our controls around access provisioning. There were several cases that we couldn’t find the access request form (paper!) for adding users to domain groups. Of course, there was an Identity Management plan that was promising to magically automate everything, but we needed something to address our needs until then.

So I created a simple PMT solution. We modified the Access Database that was used to record the content from those access request forms to generate a text log file, used a sysinternals tool to dump the Event Log from the PDC (Well, some time ago…NT4 domains! :-O) to a text file and I created a script that would compare all events of access management (creation of groups, users, users to groups) with the forms we registered. Any deviations were then investigated by the team.

It was fun to see how much was done informally by the domain administrators. That new process forced new habits to them (such as immediately informing us any time they needed to do something that would appear in the logs), solved our problems with IA and didn’t cost a dollar (at least no green dollars). Considering the number of mistakes (honest mistakes, but that were providing excessive access rights) that were identified, we actually reduced risk to the organization.

If a financial institution, that is normally more formal and process oriented could do it, why can’t those solutions be useful everywhere else?

How to make rich men use poor man's tools?

2012-08-17T14:11:00.000-04:00

I was reading this great post from Johannes Ullrich on the SANS ISC Diary (in which he describes a very nice and simple script to help using DNS query logs as a malware detection resource) when I realized that although there are tons of very nice tricks and solutions out there (normally described as “Poor Man’s tools” - PMT) that are simply not used by medium and large organizations. I’ve seen that happening multiple times, but normally what happens is:

1. Techie guy finds the solution and thinks: cool! Proposed to middle management

2. Middle management thinks:

a. “no way we will spend time and resources on this” OR

b. “it’s too simple to be good” OR

c. “I’ve never heard about this on those vendor webcasts so it’s not worth” OR

d. “oh no if do this once the executives will deny all my budget requests expecting me to solve everything with things like this” OR

e. It’s “open source”, doesn’t work in an organization like us” OR

f. “I can’t trust this thing it doesn’t come from IBM/Microsoft/Oracle” OR

g. Put your stupid reason here

3. If for a miracle it moves up the food chain, it’s denied by higher management for one of the same reasons listed on #2

So we end up with organizations struggling with problems that could be solved with those PMTs. I’m more than aware that some of those concerns, specially around maintenance costs, are not totally unfounded. But there are organizations that actually do those things, normally due to different cultures (Universities, DotCom companies), and pretty successful with that. So, what could we do to change the way that organizations deal with PMTs and increase their adoption?

I think we need to sell the idea of Simple Solutions Task Forces. Every IT group in a big Enterprise, including Security (don’t even start by saying Security is not and IT group, there’s at least one piece of it that is), should have its own SSTF. People that would look at problems and say “hey, we can actually fix that with this little script”. I’ve seen so many very expensive products that are nothing more than simple scripts disguised as pretty shiny boxes, so in the end the result may not be that different in terms of features and the cost/time to deploy the solution can be really reduced. As it would be proposed and implemented by a specialized and formalized group, all the required precautions around documentation and support would be covered.

Another option would be to just create the framework for those solutions in the organization. Someone like those Standards and Methodologies groups would put together what is necessary for anyone to implement a PMT in the enterprise: a support and a documentation model, code repository, roles and responsibilities minimum requirements. With that available, anyone could champion a PMT implementation while providing the necessary assurance that it won’t become a unsupported black box Frankenstein.

From my side, I was thinking about assembling a crowdsourced Security PMT repository and see if we can create some momentum to give these solutions a little more visibility and chance to find a place in sun. We know our problems, we have the tools; what about using them?

You don't need to be too concerned about the Cloud...

2012-08-15T15:59:00.000-04:00

1. Because your firewall rules suck

2. Because you are not applying patches

3. Because your users are all administrators of their desktops

4. Because you trust those nice charts with HIGH/MEDIUM/LOWs

5. Because you have malware active in your network…

6. …and you can’t see what it is doing…

7. …but you think the next shinny box will solve it

Maybe when you fix those you can start worrying if the Cloud is secure enough for you.

Honeytokens being used in real world

2012-07-16T10:58:00.000-04:00

Very interesting case of honeytokens deployment in this Network World article today. Here's what they did:

Here's what happened. We use Salesforce.com as the single repository for information about all of our current customers, potential sales opportunities, sales forecasts and more. It's all highly sensitive material and not anything we'd like our competitors to get their hands on.

That's why one of our marketing executives was worried when she called me into her office earlier this week. She had received a marketing email from one of our competitors. The interesting thing about this email was that it was sent to all of the dummy, or "honey token," email accounts that we had set up in Salesforce for testing purposes. The implication was that the email had also gone to all of our legitimate customers and that this competitor somehow had gotten access to the information in our Salesforce deployment.

XaaS, cloud services in general are a fertile terrain for honeytokens deployment. Don't forget them as tools to complement your DLP strategy!

Simple and effective

2012-07-10T15:19:00.000-04:00

Although there's no hard evidence for any of the tips from the links below (and it would be nice to collect that!), I've always liked simple security interventions that could reduce risk without the associated cost of implementing new tools or processes. It was interesting to see in the same week to separate posts with "cheap" security measures that can help a lot who doesn't want to be the low hanging fruit. Enjoy:

http://www.netspi.com/blog/2012/07/09/5-ways-to-find-systems-running-domain-admin-processes/

http://www.networkworld.com/research/2012/070912-10-crazy-it-security-tricks-260746.html?page=1

"We are not a target"

2012-07-03T16:12:00.000-04:00

Yes you are. Security professionals should be educating executives that make that mistaken assumption to understand how valuable their IT infrastructure is by itself, no matter what data is there. Brick and mortar criminals steal fast cars to use when robbing a bank, it’s the same thing for servers on the Internet, email accounts, FTP and web sites; they might not be valuable for the data they hold, but they are valuable tools to be used in attacks against others.

Even when you consider malware (such as Flame, Stuxnet), they still can cause you problems (downtime of IT the most common issue) even if you are not the original target, as most of them don’t include checks to confirm they are running on their targets only. Even silly stuff, like those created to steal World of Warcraft credentials, for example, will still affect your systems and can cause issues. Even if they are “benign” for you, it’s someone else’s (and someone not trustful at all) code running on your computers.

So, forget about “We’re not a target”. Even if you are not because of your data, you still are just because you are connected.

Here it is, as expected: transaction poisoning

2012-06-26T10:42:00.000-04:00

Why can't we coin cool names like that?

From the McAfee report on the "Operation High Roller":

"In addition, we observed a scheme known as “transaction poisoning” that targeted a well-known online escrow company. Rather than initiating new wire transactions on behalf of infected victims, the scheme would silently modify transactions initiated by the legitimate account holder. The original transactions were intended to go from a North American account to a recipient in the United Kingdom to fund an escrow account for auctioned vehicles. Instead, the funds were diverted to a mule account (see Figures 6 & 7).
This attack used a remote script that injected the necessary information behind the legitimate data, so the fraudulent transfer was invisible to the account holder. The script altered the following fields:
1. Bank Name
2. Sort Code
3. Swift Code
4. IBAN code
5. Account Number
6. Beneficiary Address"

We saw it coming. That's a very efficient way to deal with banks that apply two-factor authentication to each transaction.

Flame, exactly how we predicted 5 years ago

2012-05-30T16:27:00.000-04:00

This week news are all around Flame, the father of all malware. There are several interesting posts and code analysis floating around about it, but what I wanted to highlight is how Flame is following the evolution pattern I and my friends Victor and Fucs presented back in 2007 (Black Hat Europe). Some of Flame's characteristics that we talked about at that time are:

- Modular architecture: we said "The payload, the part of the bot that is responsible for its "features", can also be developed as a separate layer. It would be composed by several features modules, which receive the commands from the command layer. The bot can just download a new feature module, that is programmed to receive its parameters through a defined API"

- Script language: from our paper: "If the botnet master's objective is to avoid transferring executable binaries while maintaining the ability to have flexible bots with extensible functionality, there is also the option of using script languages."

Flame was designed to allow updates for its exploits.

Flame, exactly how we predicted 5 years ago

2012-05-29T23:19:00.000-04:00

From our paper back in 2007:

Browsers and malware

2012-05-24T11:48:00.000-04:00

So, "Google Chrome Just Passed Internet Explorer To Become The World's Most Popular Web Browser". What does that mean for security?
I think that, putting aside the always present concerns around privacy every time the name "Google" is around, it's good to have a browser with security conscious design being widely adopted. However, I think the interesting part of this is to consider the data below together with some other factors:

Source: StatCounter Global Stats - Browser Market Share
Have you noticed that browser vulnerabilities are not the key vectors being used by attackers to compromise end users anymore? The culprits of the day are Adobe Flash and Acrobat Reader. And it's easy to understand why.
If we look at the graph above we'll notice there's no browser with more than 40% of the market. So if you are an attacker and you want to write malware than hit a bigger chunk of the "victim space" it's not a good strategy to use browser specific exploits, such as those related to MS12-010. Wouldn't it be better to target something that runs on 99% of the PCs (considering that PCs are still the major malware target), or even 73%? Those are Adobe Flash and Java, respectively.
Whenever there's monoculture, there is increased security risk, as Dan Geer has been saying for years:

In biology, a monoculture--a singular species that supplants all others--is a bad thing. When every plant is the same species, every plant is susceptible to the same predators, the same diseases. Examples are as plentiful as they are sad: Consider the virus that brought on the Irish potato famine or the boll weevil that nearly obliterated the South's cotton crop in the early 20th century, and you see the destruction that human-made monocultures bring upon themselves.

Computers are no different. Computer viruses spread efficiently, lethally when all computers on a network run the same software. MyDoom, Melissa and MSBlast were a function not of the Internet, but of a Windows monoculture. They caused havoc because they were designed for specific vulnerabilities of Windows. Since one virus generally affects one species of software, any computing monoculture poses a hazard the same way it does in nature.

As always, the old is new again. Geer was talking about document formats at that time, now the discussion is around active web content. But there is hope: HTML5 has been seen as something that will allow the diversification necessary to reduce the risk. No more single piece of software necessary to browse the web, no dependence on specific Operating Systems or platforms.
But for this specific case, there is a catch: HTML5 is so powerful that there's a risk it becomes not only an attack vector, but a new species by itself, a huge new monoculture. Things like the WebSocket API could make it be the new One, the One to rule them all, the One to bring them all and in the darkness bind them (Yes! I did it! I quoted Lord of the Rings :-)). Cross-platform malware is the new threat rising, leveraging HTML5 features to exploit PC, Mac, iOS and Android.
The perspective (temptation?) of malware that can potentially run on all those platforms is certainly drawing the attention of all sorts of colored hats. Javascript worms have been reality for a long time, so there's really no reason to believe HTML5 malware won't be a rising issue in the near future. Trend Micro's Robert McArdle wrote a very nice piece about HTML5 attack scenarios that illustrates our future challenges around it.
So be it. The browser monoculture is dead (at least for now - keep an eye on Chrome's rising trend!). Long live HTML5 monoculture!

which tool to pick?

2012-05-18T16:05:00.000-04:00

A friend of mine sent me an e-mail asking for my opinion on some tools for a DRP (Disaster Recovery Planning) project. It’s a subject that I haven’t touched for a long time, but in the end the thought process around his question ended up being so interesting from a security planning perspective that I thought it could be good material for a post.

He asked me about two specific tools, LDRPS and Archer. We had a good experience with LDPRS when we worked together on a BCP/DRP project a few years ago, and someone suggested Archer to him. As I said above there’s been a long time since I worked with BCP processes, but I spent a few minutes researching the current state of those tools in order to provide him a decent opinion.

The interesting aspect of his question is that it replicates a very common dilemma we often face when we are developing tools roadmaps and architectures. The Best of Breed x Generic solution.

I haven’t put my hands on those tools for BCP, but I’m certain that LDRPS is better than Archer on a simple feature by feature comparison. LDRPS was developed by Strohl, later acquired by Sungard, two companies specialized on availability services. It’s used by a lot of Fortune 500 companies and it’s been evolving for literally decades.

Archer, on the other hand, is a GRC tool that happens to have a BCP module. It’s a tool to solve a broader variety of problems than LDRPS, and I bet that it won’t have all the bells and whistles LDRPS has for developing and testing disaster and business continuity plans. But (and there is always a but)…

The wider scope for Archer can be the source of its weakness on this case, but it’s also its major strength. There are a lot of common steps and similarities in the BCP/DRP processes and other processes supported by other Archer modules, such as Risk Management, Compliance Management and Vendor Management. For all these processes it’s necessary to identify data, assets, locations and other components of the organization, establish ownership, value/impact and interdependencies. And that’s what could make Archer the best pick for my friend. Depending on this organization’s strategy for those other processes they might be able to leverage some work already done or re-use the data being gathered for the BCP project on those other processes. They may end with a tool that is not the best available for developing Business Continuity and Disaster Recovery plans, but they might be getting more value by leveraging the data obtained during that project on other fronts.

Integration and data sharing is one of the key aspects of a successful security strategy. Good security architects and managers will always consider that when choosing the tools to implement that strategy.

Grimes article on firewalls

2012-05-16T16:20:00.000-04:00

It’s always interesting when an article or blog post generates multiple responses from the security blogosphere. It lets us gauge the general opinion of that particular idea or concept. It wasn’t different with this post from Roger Grimes, “Why you don’t need a firewall”. It sounds very similar to the general rationale for the Jericho project, but those guys have clearly stated that the firewall doesn’t have to be removed, but it assumes a smaller role in the new security strategy.

There are similar opinions about the article here, here, here and here. Some different spins, but the general understanding is that the firewall is not a silver bullet, but it has its use. The most important thing to consider when assessing the firewall value is to understand the value of choke points:

In military strategy, a choke point (or chokepoint) is a geographical feature on land such as a valley, defile or a bridge, or at sea such as a strait which an armed force is forced to pass, sometimes on a substantially narrower front, and therefore greatly decreasing its combat power, in order to reach its objective. A choke point would allow a numerically inferior defending force to successfully prevent a larger opponent because the attacker would not be able to bring his superior numbers to bear.

(from the “Choke Point” Wikipedia entry)

Firewalls are also valuable enablers of other security tools, such as IPS/IDS and deep package inspection systems. Deploying those systems behind firewalls reduce the amount of data to be inspected and the number of events generated for investigation, reducing capital (hardware) and operational (people) costs for those controls. There are some decent metrics out there for sizing deployments of those tools based on the amount of traffic being monitored, so it should be straightforward to factor them into a cost/benefit analysis for firewalls.

One can argue that we should also consider the additional costs from the firewall deployment itself, but the controls above are just one example of things that will cost less because of (well managed) firewalls. Those reductions sum up to a point where not having firewalls is just a very bad business decision.