Gary McGraw has written an article explaining why you need a software security group if you want to have a software security initiative. Saw this flew past Twitter via Jeremiah Grossman.

This is a great scenario that I’m sure happens everywhere (yes, everywhere):

…if you go to the development organization and ask about software security they will immediately refer you to the network security people. “We have a department for that security stuff,” they say while ushering you out the door. But when you make your way to the network security department and ask them about software security, they say something like, “Yeah, those developers really should produce code that doesn’t suck. Those guys ruin our perfectly configured network with their broken applications.”

He also throws this gem in:

To make perfectly clear that this is a management issue, ask yourself who gets fired when your firm experiences a software security problem? Who gets rewarded when your firm does a good job with software security? If the answer is “nobody,” then you have a real problem.

The only downside to this set of data and underlying conclusion can be exposed in the last few paragraphs of the article: the size of the companies McGraw deals with are probably pretty large. In other words, they have the opportunity for real security groups. I’d wager a vast majority of firms don’t have that freedom (or budget), and have to make do with, at best, part-time security. Sadly, this either comes in the form of small, annual security tests after the real work is done, or some unlucky bloke’s duties which are shared with his day-to-day tasks and projects. And we all know which half of those duties he will be pressured to do first. (Let alone the arguably expert-level amount of knowledge one needs…)

Even deeper than this being a management issue, this is an issue of how important security is. If it is important, then management will maybe properly do it. If it is not important, then you better just hope you are a big enough org to create a dedicated group for it.

John Strand has a great, quick blog post over at pauldotcom.com on tapping and training your system administrators as a security asset.

There are actually quite a few similarities and strengths that system (and network) administrators have that parallel or complement security professionals. Disclaimer: I *am* biased since I am a sys/network administrator as my major function in my day job. (And yes, looking to get deeper into security in a more full-time role.) Here are a few of my notes I’d throw down.

1. I’ve said it many times before, but I believe if you truly want the real story about security in an organization, you get as low down into the trenches as you can get. This usually means your IT staff. And often means your desktop support staff, admins, and even app coders; but most probably admins. (I knock the desktop guys [I used to and still pretend to be one] only because they tend to be evaluated by their customer service. They don’t get rewarded for properly configuring a host-based firewall, but they do get rewarded for disabling it and allowing Joe Blow to get back to work.) Incidentally, if you want to know the health of a company, I’d also say your admins are a good source; they touch and know a lot!

2. Administrators are used to being at the end of the shaft, even more so than desktop specialists or coders. More often than not, the admins are the glue keeping all the disparate parts working together and covering for other IT sections that aren’t really up to snuff. They also tend to absorb things like poor applications or bad business process decisions that impact IT. They likely, along with desktop dudes, to see firsthand the people who violate policy. Bottomlines usually end with the administrators, and they’re used to getting it from management and from other IT persons. If anyone in the company is used to putting on the brakes and talking policy and standards and getting people to line up with them, it is your admins.

3. If you want to roll out a security initiative or project of any type, more than likely you’ll need an admin to give you access, gather logs, set up servers, configure the network for your visibility, provide documentation and diagrams, or be next to you during an incident response. Basically, get to know them and get on their side (and they on yours). They’re also the one who will make or break your policies, even more so than desktop dudes, especially if they need to understand and follow the steps on, say, how to harden a server. (Many desktop workers aspire to be systems workers, so their is also a tendency to look to the admins for leadership, formally or informally; compare paygrades if you doubt this.)

4. They also want to make sure things are done right. Admins are usually time-sensitive and risk-averse, and they don’t want things to break, they don’t want to be blamed when things break that they didn’t cause, and they want to troubleshoot intelligently. Even the worst admins tend to have the beginnings of these habits. It’s just a result of a ball rolling downhill.

5. That “A” in CIA is a shared role with the admins. It is also their duty to monitor and maintain availability for the masses.

6. Everyone learns about least privilege and separate of duties, but out here in the real world, business IT is run by admins with godlike access. That’s just how it is. If you think otherwise, you’re not thinking of all the ways they can end up pwning you. This means they really absolutely need to have a mind for security if you expect to get anywhere. If the admins don’t do it, then you’re stuck with a top-down approach which doesn’t always work. Even if bottom-up approaches get mired in budget constraints and buy-in, you can still do a lot to combat insecurity by having security-minded admins. Think about code. To secure code, you need to bake it into the creation with skilled coders and low-level policy. Same thing with systems and admins.

7. It is my really quick, knee-jerk opinion that every real IT security pro needs some practical, hands-on, systems or network or desktop administrator experience. This helps immensely on various levels. This isn’t always true, which is why I always keep this opinion short!

Read an interesting story this morning about a lawsuit from a Texas company accusing a Minnesota Public Radio reporter of hacking into their web system. Read the full article to get a good idea on what all went down, especially the last 3 paragraphs which I feel really get to the heart of this somewhat complex issue. Here’s the last quote from the CEO of the Texas company who had weaknesses in their website:

“… in our contract, we had 60 days to fix any problem. But there was still an unauthorized intrusion, and that was wrong.”

If you ask me, you had completely dumb weaknesses in your site. Just because you offer 60 days to fix something doesn’t mean you get a free pass from even the most assinine security issues. They fucked up.

I’m not a judge, but my kneejerk reaction to this lawsuit would be to have the Texas company thank the reporter for reporting the weaknesses in their web presence; a service tendered for free. The reporter should learn that this isn’t such an easy thing, to just twiddle with a website and call it good. She was stepping into murky waters and should exercise more caution in the future, but at least it does not sound like she had malicious or self-serving intent. And the general public and every employee and customer of that company should thank the reporter for exposing an issue that likely would not have been fixed otherwise.

I would hope this doesn’t even progress past the prosecutor.

I’ve been recently digging deeper into network DLP (part of a PCI initiative in an organization). I’ve long narrowed my eyes about the concept of the DLP space, but I feel a lot better about it lately. Let me briefly explain…keeping in mind I am discussing network DLP and not endpoint DLP.

My original thinking about DLP has always been how it has so many limitations. It is fun to make a list of all the ways you can circumnavigate the functions DLP provides. This always made me sigh in exasperation about DLP (data loss prevention!) as a security tool to prevent data loss. It’s not that I wanted DLP to be infallible, but I thought it was silly that even simple things could defeat it, like HTTPS/SSL, or a password-zipped file.

But now I believe DLP is not supposed to strictly be a security tool. DLP should better be labeled as a Sensitive Business Process Identifier. What DLP really does is identify and alert on business processes sending XYZ data over channels they’re supposed to be using, or they should not be using. Instead of stopping a malicious individual from exfiltrating information, DLP really wants to act like bumpers in the gutters of a bowling lane: make sure valid business processes aren’t using poor channels to move data, and somewhat log/assure when it is used properly. My old thinking involved malicious activity; my new thinking involves business-valid activity. That’s a big difference!

Does this satisfy PCI checks? Technically, I guess so. But does it offer much assurance that data is not exfiltrating a network? No. Does DLP make a security geek feel good? Not when considered alone. When considered as an advanced item in a mature security posture, then perhaps it is merely ok.

A very valuable side benefit of DLP’s approach is to drive identifying where sensitive data resides and transits. This is almost worth the cost of DLP to many companies that have no idea where this stuff sits or moves.

I find it interesting that so many security questions are addressed by asking more questions. What level of logging should I have? Well, that depends, what are you protecting? Do you have staff to watch logs? Budget to buy something to watch logs? What do you expect from logs? And so on… One answer usually just doesn’t fit every situation.

I can actually bring this back to my old discussion on security religions. Some people believe in absolute solutions that are secure and cover every situation. Others believe in incremental security, where you may have to layer protections to cover all your bases, and maybe not any layer is all that secure in itself.

This takes on a new dimension when you talk about scope. Are you talking about security on a macroscopic scale (e.g. national, global, internetwide) or microscopic (e.g. any organization, a home office)? Scope can have even more implications such as budget, coverage, and so on, but macro vs micro is the best start.

I often engage in security discussions that can lead to heated argument if the concepts of security religion (of participants) and scope (of the discussion) are not addressed up front. Participants can become violently argumentative, when they’re simply talking about different things (global DNS security vs your SMB DNS presence). Hence, security discussions or questions, to me, almost always begin with more questions, questions designed to fit the scope and religion, while also answering other necessary questions that eventually lead down an informal risk valuation…

Bejtlich has posted a really nice beginning (furtherment?) to the discussion of digital monoculture vs heteroculture (or control-compliance vs field-assessed). I don’t really have strong feelings on either side, but the discussion itself is incredibly interesting to think about. I think there are pros and cons to either side, and I’d be willing to bet various important factors will dictate the value either approach brings. Things like organizational size, need to prove a compliance level (gov’t, defense, or just large and public?), and quality of both internal IT and internal security staff.

While I’ve previously not enjoyed the approach that the Jericho Forum has employed to back their vision of the perimeter-less organization, it does help that position to think of an organization being a heteroculture and using field-assessed measurements for security efforts. Typically my opinion is perimeter-less security (as horrible a term as that is since there is always a perimeter no matter what scope you lay out) and defensible endpoints are something you can only do when you go balls-in all the way, which is rare. Still much of our security industry only goes into an approach like that on the barest of levels, which causes it to make no sense.

That’s not to say you can’t have a middle ground on the actual discussion on Bejtlich’s post. I only bring up the Jericho position because going to the extreme on field-assessed hetergeneous environments fits nicely with their world view. I probably fall into the bucket that says good measures of both approaches will probably bring the most value.

I’ll never be surprised that Bejtlich falls on the “field-assessed” side of this discussion. In fact, I think most trench-friendly security techs will be sypathetic to that side because it deals a bit more in fact and reality and specifics. Compliance is really made to be friendly to non-techs, both on an assessment side, but also on the consumption of the reports. It’s also the side I tend to be more friendly to, as well.

At work we’re continuing to chip away at dealing with PCI requirements. There are lots of lessons to be learned from such a project. One of the more painful ones: It is relatively easy to say (and even convince an auditor!) you meet each bullet requirement, but it is difficult to have effective security without improving your staff. There are a number of bullets that involve logging, reviews, and monitoring…things that are driving SEIM/SIM and other industries. But these are also things that security geeks realize really need analysts behind the dashboards and GUIs. Otherwise these products only skim off the very slim top x% of the issues, the very easy ones to detect. And miss a hell of a lot else.

Mogull over at Securosis points out an article on a lawsuit against a POS vendor and implementor for passing on insecure systems that violated PCI. Or something to that effect.

Either way, this is a Big Deal. This is something I’ve been patiently waiting for over the last couple years as PCI has gained traction.

I’m a little early, but I believe 2010 will be the year that The Security Blame Game becomes further legitimized as a business model. In other words, I feel that we’ve long had a quiet blame game when it comes to security, but as more becomes required to disclose and more cost is moved around from party to party, the quiet blame game is going to get very public, very annoying, and very costly.

Which is especially scary because security is not a state or achievement. You’ll end up with impossible contracts and a bigger gulf between what people think is secure and what is actually in place. And it will be shoved deeper into the shadows when possible. And compliance will continue to be questioned despite the improvements and exposure it can provide.

Here are some other observations I expect to hear more about in 2010:

• more exposure of stupid configurations, implementations, and builds of “secure” systems
• industry needs to clean out the security charlatans, and cost/lawsuits have to do it
• more pressure to do security “correctly” which is far more costly than most realize

And one thing I *hope* happens more:

“Turnkey” security tools whose vendors brag that you just turn them on and let them loose (sometimes with one-time tuning) and you’re secure. And you don’t need staff or extra business process or ongoing costs other than licensing. Bullshit. Every security technology needs analysts at the dashboards, at the very least. Hell, even in just plain old IT operations, far too many issues and incidents are found by third parties or by accident when looking at something else. It’s an epidemic (and an indirect product of economics) that will not begin to go away. I really hope the idea of security process continues to be foremost, and the idea that something is “secure” begins to die. I doubt the latter will ever happen, as it has been decades so far in computing; and longer in the realms of security in general. I’m not saying we need to solve security, in fact I want to say we need to solve our perception of it, so that we don’t actually ever ask or expect to “solve” security…