10 Things Your Auditor Isn’t Telling You

June 24th, 2009

This is NOT intended to be a mean and/or overly cynical post. By no means do I imply that auditors are bad in general, in fact I have been one and still do audit and compliance work today. But there’s some unspoken truths that I’ve encountered over the years, from both sides of the fence. Things that people think and won’t say, and some common circumstances that are just a fact of life in the world of auditing and regulatory compliance. Here goes.

  1. I am actually just following a checklist. And that’s that.
  2. I do not understand the technology I am auditing. This is really common, and it shouldn’t come as a surprise. Too many technologies, not enough technically skilled people in audit.
  3. The well-dressed, experienced greyhairs came in and sold this deal, but I graduated from college 8 months ago and went through ( E&Y || IBM || Deloitte ) auditing bootcamp. And numbers 1 and 2 on this list are present, too.
  4. Most firms are really incentivized to help you pass. Why? Because in many cases, you can fire them and get a new  firm that is “easier” on you. This is not a universal truth. But it’s a big business, and no firm wants to get a reputation as “very difficult”. Leading us to…
  5. Show me a viable set of compensating controls, and I’m liable to pass you. Or at least get you a neverending series of extensions. This could be exactly the right thing. Or not (if #1 and #2 are in play). They have to be reasonable though. (See #10)
  6. Auditing standards suck. Although ISACA and other organizations are trying really hard to help with this, try finding a commonly-accepted auditing standard for Cisco ASA Firewalls, or Ubuntu servers. Lots of random sites, some more well-known than others, but still no universal standard.
  7. Compliance regulations suck. They are almost all poorly written, vague drivel with 50 pages to somehow ambiguously describe one central point. PCI is much better, but still lots of grey area. This, combined with #6, leads us to…
  8. You can’t have it “your” way. I’ll work with you, in a polite and professional manner. All part of the schtick. But at the end of the day, I’m following my auditing methodology, with my particular interpretation of things, and whatever skills and knowledge I bring to the table. So yes, it’s all about me.
  9. I know more than you. The antithesis of numbers 1, 2, and 3 on this list. Sometimes auditors really do know a LOT about an area or areas, and they can really guide you. Two problems usually occur here. First, egos get in the way. Major gender in IT? Male. Do men stop and ask for directions often? No. Second, money and time. Auditors can be educators, sure. But most of the time, they’re there to gather information, provide a report with recommendations, and then check back in. They’re usually billable, and many organizations aren’t paying them for a huge number of training hours.
  10. Covering my ass is my major goal. No auditing firm will forget the lessons of Arthur Anderson. Although some firms may still be less-than-ethical, most are 100% aboveboard and will pester the everlasting crap out of you to get enough detail to justify audit results and recommendations. This is ultimately a great thing for everyone, as audits are probably more thorough. But no one likes to admit this.

And here’s a bonus:

  • I know you probably don’t like me. And that’s a shame. Better communication and collaboration with auditors would go a long way toward improving audits, controls, and likely security as a whole.

Information Security

Data breach disclosure: Business vs. Security?

June 18th, 2009

And what about ethics?

This is not quite a book review, not enough time for all that, but I did just finish reading an excellent book, really the first of its kind that I’ve encountered. The book “Adventures of an IT Leader” by Harvard Business Press is written as a story, not some horribly dry academic treatise on the subject of managing IT. The plot, in a nutshell, is about a business leader in a turnaround company (new CEO) who is asked to take over IT and shape it up. He knows nothing about IT management, is not technical, and is under a lot of pressure from day one. The book then goes through a series of events and circumstances in this guy’s first year on the job.

I loved it. In fact, for any technical person in IT or infosec who wants to get a good grasp of business decisions and the process you’ll go through in making them, this is a fantastic read. A little contrived, and if you’ve been around a while, you’ll recognize some things and already know others, but a fun book nonetheless.

Why am I talking about it, though, and what’s the relation to the title of this post? Well, about midway through the new CIO’s tenure, the company has a security issue. This is a major topic in the book, although they stereotyped us “security types” a bit (purple hair? Skull T-shirt? C’mon, that’s only for Defcon for most of us). I won’t give away too much plot, overall, but here are the relevant facts:

  • Company has sensitive financial data on people (they process loans)
  • A fair-sized risk exists due to coupling of an acquisition’s network, security and IT have known about this for a while. Nothing was done (budget priorities.
  • Company’s site experiences a DoS attack, coupled with some odd behavior that makes them THINK customer data may have been accessed. They can’t find definitive evidence (logs, etc) however.
  • Legal wants them to be proactive and notify customers to be alert for strange account activity.

This brings us to the executive meeting where everyone has to decide what to do. To make this short:

  • New CIO recommends a pretty drastic plan to wipe systems and start clean to make sure no more compromises exist. 2-3 days of downtime, planned for a weekend, still a big impact. We all know this isn’t that practical in real life, either, but it’s not wholly unrealistic.
  • CEO says “Hell NO” to notifying customers AND shutting down systems. In other words, no GNUs is good GNUs.
  • Head Legal Counsel and new VP of Loan Operations (new CIO’s replacement) challenge the CEO, saying they should notify customers to be proactive and wipe the systems.
  • CEO promptly fires them both. Meeting adjourned.

Wow. This was a very interesting case study, and one that did not seem TOO unrealistic to me, frankly. There are some later follow-ups in the book, where the CEO explains that business can be a gamble sometimes. Risks have to be taken, regardless of a “higher moral ground” kind of stance. Also, keep in mind that there was no DEFINITIVE proof of data leakage, just suspicions. Other hacking activity (like the DoS) was present, but a data breach was not certain.

What do you think? Aside from legal requirements to notify, if a company feels that it can protect its reputation and save jobs, stock price, etc…is there an occasion when the “silent fix” is the right approach? In other words, clean up the backyard but don’t say a word about it? What if they did the risk analysis and determined there was a 80-90% chance they could pull it off? Mind you, I’m not necessarily espousing this approach, only debating.

Information Security

BS Filtering for CISOs: Vendors and Third Parties

June 7th, 2009

So it’s time to add a new installment of “BS Filtering for CISOs”. AS I stated in the first post of this series, BS filtering is a critical skill for CISOs everywhere, just as vital to the success of an information security team/program as content filtering and packet filtering for the technical members of the staff (not to suggest, of course, that the CISO isn’t or hasn’t been technical, far from it).The concept of “BS Filtering” does not always mean that people are deliberately trying to con you, though; you may just need to read between the lines, dig a little deeper into statements, etc.

This is particularly the case for dealing with vendors and 3rd parties, where you can get easily misled, contractual language aside. Here are a few tips specific to security professionals that I’ve gleaned over the years.

  • Understand the business motivations first. By this, I mean understand what each party wants to get out of the negotiation. In the case of a vendor, it may simply be another sale or a new customer relationship. In the case of a business partner, they may be looking for a new sales or marketing channel, a means to increase revenue directly with you, or they could even be looking for a strong reference partner/customer. Knowing what the underlying motivation is can help you to have a more intelligent business discussion about risks and rewards for both parties involved.
  • Do your homework. This sounds like common sense, and to some extent it is, but there’s a few concrete examples for security pros that can be useful to keep in mind:1. Talk to customers, preferably those in the same or similar business as you. You need to get an idea for how security has been handled by this vendor or 3rd-party during the course of their relationship. Put together a list of things that would concern you, and ask to speak with a customer they’ve had for at least a year or more. If they are reluctant to do this, you should be extremely skeptical of doing business with them.

    2. Ask them how they handle sensitive data covered by compliance regulations, if this applies to the scenario. Particularly with the advent of cloud computing and other hosted/provisioned applications and services that are remote from your data center(s), this becomes absolutely critical.

    3. Related to #2, ask them how they will demonstrate adherence to your internal and organization-specific security policies governing sensitive data. How will they keep it separate from other customer data? What guarantees will they give you? How will they respond to a data breach? There should be some contractual language crafted around the answers to these questions, once you’ve had the discussions.

  • Ask to see a SAS70 (at the least) or other indication of security in the area where your data/systems/applications will be housed. If possible, arrange a site visit for you to personally inspect the premises and do your own due diligence. I’ve fought for this and won before, and so can you.
  • Ask for audit results if possible. Especially those related to your particular data types, such as payment card data.
  • Inquire about configuration and hardening standards, and which the organization uses. Do they follow CIS guidelines for Windows builds? Do they use the DISA ESX controls for hardening VMware platforms? Ask to see proof of the build (or image maintenance/deployment) and how often it is audited.
  • For vendors hawking gear/software, ask about the volume of support cases maintained and CLOSED on a daily/weekly/monthly basis. Inquire about average turnaround time for support cases, and of course ask to speak to customers before you buy. This really comes down to availability at the end of the day, if the product doesn’t function properly it may be largely useless.

These are just a few of the “anti-BS considerations” you will need when evaluating business partners, vendors, and 3rd party providers. This doesn’t take into consideration the majority of typical operational considerations like uptime, SLAs, etc. For security pros, the most pressing issues are related to handling of data, adherence to internal and external compliance and policy requirements, and availability for security-specific products and services.

Information Security

No more free bugs? Is bullshit.

May 14th, 2009

So this will be hard to swallow for some. Particularly those who idolize folks like Charlie Miller, Dino Dai Zovi, and Alex Sotirov. Or whoever you know that found some amazing hack and paraded it around to win themselves a few minutes of supergeek fame.

Business 101: You can’t forcibly create a market where there isn’t one. It doesn’t work, it never has, it never will. So for those “vulnerability researchers” who are complaining how they are getting the shaft from software vendors who won’t pay them for their software, I hate to break it to you, but you’re shit out of luck, methinks. I think you inevitably have one of three options:

  1. Keep finding bugs because you love finding bugs. Get your little minute of fame, and maybe your new MacBook or whatever, and STFU.
  2. Sell your bugs to WasiSabiLabi or iDefense or some other marketplace. Maybe even an underground marketplace if your ethics are questionable.
  3. Stop doing it. Get out. Find a new hobby. Get some sun, maybe - slowly, though, that pasty skin will burn if you’re not careful!

In a recent article in SC Magazine, Dino Dai Zovi states the following:

“Vendors have been getting a freebie for a while,” Dai Zovi said. “[But] why would I want to sit down and volunteer to find a bug in someone’s browser when it’s a nice, sunny day outside?”

Well, great question! Just DON’T! Seriously, are we all supposed to have some sympathy for folks who volunteer their time to find software bugs? Another dose of reality: all software has flaws. I can live with this. It’s just a part of business. So stop trying to make it seem like it’s these terrible, sloppy vendors who code so badly that SuperSecurityCoderMan has to come in behind them to show them all how bad things really are! Geez. Just SO SICK of this. I respect your skills, bro, but either help the community, take your 15 minutes and move on, or just stop with it already.

The other argument I hear is that “if I didn’t find this bug, some evil h@X0r would”. OK, let it happen. Seriously. If it happens, it happens, we can’t avoid the inevitable forever. But lose the martyr act. I, for one, am over it.

Information Security, Rants

Watching the Watchers…Redux

April 28th, 2009

Keeping an eye on those in power has always been a staple of relatively open governments and well-organized IT shops. Let’s focus on the latter, given that a discussion of the former could easily lead to rants. Visit EFF for more info on THAT area.

Keeping an eye on IT people with greater privilege levels has always been a challenge. Obviously, this could extend to NON-IT staff as well (Enron, anyone?), but in the information security division, we’re often dealing with abuse of privileges related to something or someone in IT. I really see four distinct levels of privilege monitoring that need to be considered:

  1. The System Level: This is the realm of SysAdmins, who actually manage systems and make changes to them. Often, these teams will have Administrator or Root privileges to groups of platforms.
  2. The Application Level: This level pertains to the DBAs and Developers of the world, who may have some degree of control over systems by extension of their control over the critical apps *running* on the system.
  3. The Network-Infrastructure Level: This level relates to the network “plumbing”, or pieces and parts that hold the environment together. Network admins fall into this category.
  4. The Backbone or Service Provider Level: Plumbing on a “macro” scale.

Most of us tend to focus in our organizations on the first three levels. We’re all using the traditional mechanisms to accomplish this, too - tools like “su” and “sudo” for *nix systems, UAC and “RunAs” for recent Windows varieties, and logs, logs, logs. Applications and network device OSs have their own mechanisms, too, most similar in nature to tools like “su” and “sudo”.

What about the backbone level, though? What can we do to exert “control” over what passes through? We’ve certainly got end-to-end encryption, but that may not be practical for everything. Simply monitoring Web browsing habits can reveal a lot about us, and much of this traffic is totally open. Recently, this very issue came up in Europe, as reported by BBC News. With all the talk about Cloud Computing, and sending more data and transactions outside our traditional IT infrastructures, we should all be concerned with what access people have to our private and sensitive data, habits, etc. Another issue: how do I know for certain that my private data is deleted after I request that it be removed from some Web site/service? All good questions. There are good and bad aspects of “watching” - for example, I don’t particularly care for my government spying on me (especially in the name of “anti-terrorism”. Sheesh.) But keeping an eye on those who are in positions of trust and authority? All for it.

Information Security, Musings

Happiness is a Warm…War-Dialer

April 19th, 2009

***Just gave my “History of Hacking” talk here in Tyson’s corner, and it reminded me that I really liked this post from last year on a different site. So I am re-posting it here…enjoy.***

So I just read this:

http://www.networkworld.com/community/node/29609

In the article, Ronald Bartels brings the old school h@x0rama flooding back with his discussion of hacking voice and voice services. I liked his analogy of Kevin Mitnick and Steve Jobs (aka “Berkeley Blue”), where he makes the point that system hackers seem to get in more trouble than those who abuse the phone system. Probably true, except all the early hackers messed with the phone system and now no one gives much of a damn since the crown jewels are usually elsewhere.

Overall, though, he is right in saying that lots of today’s most common infrastructure voice gear, PBXs and the like, are essentially sitting ducks right out of the gate. Well, of course! They’re complicated computer systems more than anything else, and we all know about those dang complicated computers - they’re just not secure! Not out of the box, anyway. This easily leads to a Shackleford Soapbox rant about the merits of basic system hardening and lockdown - everybody pays lip service to it, few do it, even less do it well. BUT….

We won’t go there today. Instead, the most interesting parts of Bartels’ posting is the discussion on detecting fraud and other criminal activity through Voice IDS/IPS and behavioral rules. This, to me, is where the real intellectual stimulation happens. I am a sucker for any discussion of behavioral monitoring, because a) we are NOT good at it in corporate America yet, and b) there are MANY complicated facets to consider. Let’s break this down a bit:

  • Could a simple pattern of “war dialing” or “demon dialing” be easily detected? You bet. A sequential series of inward dial attempts from one or very few sources would be highly suspect, and this is obviously NOISE that you do not want. Even if you know the probability of anything answering is minimal, still a good idea to block noise if you can.
  • Voice speaker recognition signatures? OK, I get it. Record the voice, match the recorded profile to a set of origin numbers, yeah. Cool! Practical? Ummmm, no. Dude, there are like 4 companies in the world that give a damn about Voice profiling. With signatures to boot. Geez - big market!
  • Pure behavior patterns make sense. Junk coming from a number or series of numbers? Got it. Strange dial times/directions? Yep, got that too. Vulnerability/exploit signatures specific to the phone network and equipment? OK, still with you. But here is the $29 million question: who the hell is going to LOOK at any of it? And analyze it? And baseline it, track it, diff it, etc? Simple answer: NO ONE. That’s right, 99.9% of companies do not have the incident planning and response capabilities needed to even begin to do this, let alone analyze it and understand it.

In too many penetration tests to count, I’ve busted into some system or another using war dialing techniques. There really is too much crap out there that isn’t secure, left open for vendor support staff or remote applications or whatever else. But given the proliferation of behavior-based security analysis on traditional data networks (sarcasm- there is not a whole lot of this being done), the notion that security managers will even RANK this on the budget-spend-o-meter is not realistic.

Information Security

Security’s Role in Downsizing

March 23rd, 2009

It’s an unpopular topic for sure - letting people go from your organization. Firing, downsizing, “rightsizing”, whatever you want to call it, it’s an unpleasant experience for everyone involved. For security folks, however, there’s a lot we need to be aware of prior to, and during, layoffs in our organization; when people lose their jobs, or suspect that they soon will, they can do some not-so-ethical things. People may steal sensitive data, sabotage people, projects, and assets, or log back in with their old credentials to just “snoop around”. Whatever the case may be, here’s a list of things we need to do and think about from a security perspective:

  • Monitor logs: We should already be doing this as a security best practice (or perhaps because we want that coveted compliance checkbox). However, within the realm of log monitoring, we can shift our focus to events of a particular nature for short periods of time, and this is the case during layoffs. For example, you may want to start logging successful logon events to critical or sensitive resources (many don’t due to the volume of alerts). This can help you observe the patterns of access to the data - are people accessing the data more than normal? Are their access times a little peculiar?
  • Watch the back door: Keep an eye on VPN and other remote access methods. Much like log monitoring, you’re probably doing this already - however, you can shift more of your attention to watching events on these devices and monitor users coming into the network this way to see if they’re doing anything a bit out-of-the-ordinary.
  • Monitor physical access: Get the physical access logs of the buildings where soon-to-be-unemployed people work. Again, you’re just paying a little closer attention to patterns of behavior than normal. People coming in on weekends or after normal hours, staying late, etc.
  • Institute strict change monitoring of code and files: The recent case of the Fannie May contractor who implanted a logic bomb in a program should give us all pause. Although full-blown sabotage is fairly rare, it definitely happens. Any folks with access to code should get extra attention, and so should their code. In fact, I want a daily list of changes in their code, and you should seriously consider implementing a two- or three-tiered QA and analysis program for a short time to ensure no malicious code is inserted. Is this tedious? Hell yes. Could it save your ass? Same answer.
  • Revocation of access to resources: This is the classic problem with people let go from organizations. We need to disable or terminate their accounts and access to resources, and we’re often left to absolutely archaic methods to keep up with what they had access to in the first place. Things like spreadsheets. Emaiil distro lists. Real CUTTING EDGE technology like that. Or even worse, our own flawed memories. If you have a user provisioning or IAM system in place, this gets a lot easier.
  • Reclaiming corporate computing assets: Getting laptops, PDAs, 2-factor tokens, and the like back in the organization’s possession is also something security should be involved in.
  • Forensics: Depending on the circumstances, you may need/want to perform a drive duplication and/or forensic analysis of aforementioned computing assets. Usually, this is the case when someone is terminated for cause, and the company’s CYA instincts kick in for self-preservation in a court case or prosecution.

I’m probably missing a few considerations, and any comments are welcome. One thing to note here - some of these items implies that security teams have prior knowledge of the layoffs or terminations. In WAY too many organizations, HR teams don’t share this info and work side-by-side with security to do this effectively. If you’re in one of these organizations, you should lobby HARD to change this behavior. After all, our job is to identify, manage, and monitor ongoing risk. The risk-o-meter goes way up during layoffs and terminations, and given that we can do so much to prevent mishaps, we really should.

Information Security

The Economy Affecting Infosec? Survey Says!

March 20th, 2009

Greetings, security people! A while ago I posted a few questions to the SANS/GIAC community asking how the economy was affecting security programs within their organizations. I had a handful of responses, but not too many. Then, thanks to a suggestion from Christophe Veltsos, I created a simple SurveyMonkey survey and got a total of 23 responses. As promised, I am sharing those results with the community, since it’s always nice to know what others are up to. Here goes…

QUESTION #1: What types of policy changes and over-arching security philosophy/mindset/risk tolerance changes are occurring as a result of fewer staff? For example, are you “locking down” Internet access more than usual since you have less time and staff to interpret user requests? (19/23 answered this question)

  • none
  • No impact so far — I am in healthcare and we are moving to an electronic health record so more than less emphasis on policy.
  • No, the people who remain have more work to do, so security is suffering as a result. It is seen as less of a priority than “giving the user what they want.” Daily, I see dozens of machines with no critical updates applied and systems with blank passwords. Security doesn’t exist here.
  • Unfortunately nothing different is happening and that’s (IMHO) the problem. Fewer IT Security staff means less hands to protect the enterprise, and less prevention / detection / response.
  • [M]ostly we just do not have the time and resources to properly handle threats. Because we are a university this means they are b[e]ing left unmanaged.
  • More dependence on policy compliance
  • Actually, the unfortunate result of having less IT/IS staff is that we are seeing a tendancy to have what are deemed business critical applications put into production, w/o the thorough review like we had done before - which in my opinion is opening the door to bigger problems that may never be analyzed, unless a breach takes place. The time, money and resources we used to have are now no longer a commodity, and proper risk analysis procedures are not critical like they used to be.
  • We have less time to analyze security problems, so tolerance of user mischief is far lower. We don’t have time to listen to mitigating factors and hold peoples’ hands.
  • Finally fear has occurred and now mgmt wants postings and awareness to the end users for their home systems. Internally, I still am not allowed to impact the users by trying to do any of the workarounds to the recent issues on Excel zero day, Adobe etc
  • we have not lost any staff. We only have one analyst (me).
    No workload is the same, there is no funding available. We still have to investigate ways to secure and meet policy, but there is no funding for anything. Waste of time.
  • We are extending replacement cycles which is having the impact of potentially losing support on hardware/software and may necessitate unplanned and unfunded purchases.
  • Insider threats from people being laid off
  • No
  • No strategic shifts in policy being contemplated
  • No changes, just longer hours. Any new automation of processes that requires new hardware or non-open source software is just not happening.
  • As the business shrinks, the security investment increases. IT and audit staff levels are staying level as supported staff decrease. There is so much legal and client pressure to improve information security that we see this as a necessary investment. We are investing in improving technology, education and procedures.
  • None
  • n/a

QUESTION #2: What types of security operations are taking a hit? Reviewing logs or IDS info less often? Resolving change/exception tickets more slowly for firewall and other access? (18/23 answered this question)

  • none
  • N/A
  • Everything is falling by the wayside. Security doesn’t matter until there is a breach. Then it is CYA time for a while, then back to business.
  • Even with a SIEM consolidating IDS, Firewall, Remote Access, VPN, Antivirus, and Active Directory (authentication) log sources we still are falling short to monitor them proactively. Response on tickets to our group has gone from measure in days to measured in weeks or even months.
  • Ids is unreviewed. VPN is not being appropriately managed. Firewall rules are not getting attention. Log review happens only during investigation.
  • [A]pplication firewall setup (web service filters, for example); service creation
  • Speaking only for my team: 1. Log analysis 2. Risk Analysis 3 Lack of vendor support for products - no money to renew. 4. Daily operations tasks, like level 3 tickets take much longer to resolve
  • Logs are getting less looks. Keeping up with the event console is about all we can handle right now.
  • None, they are looking to purchase Core Impact to compliment our Nessus and IBM ISS IDS tools and improve reporting. My group recently changed from Checkpoint to Cisco firewalls and will move the FW admin to the network team to improve the process. They are looking to hire me a Sr level cyber analyst so we are looking to improve, more people, more products
  • [W]e will not implement new projects, such as IDS/IPS due to hiring freeze.
  • Anything that costs money.
  • No hit yet, but unlikely to replace people if they leave.
  • None, actually still growing. Adding positions to address gaps.
  • Things happen more slowly of course, with fewer to do the work.
  • None. Rather, we are investing in more efficient security configurations and oversight. HIDS as part of a desktop security suite, rather than complex NIDS/IPS. Improved SEIM to make incident handling and response less demanding on staff, etc.
  • Lost a staff member who handled database ID provisioning, DB auditing, etc. Having to figure out how to split those duties across other folks.
  • Everything is just getting a budget contraction.
  • Personnel

QUESTION #3: What items are getting cut out of the budget? (21/23 answered this question)

Additional answers (the “things I missed” category):

  • travel and training reduced
  • 2 factor authentication. For the first time ever they’re cutting our budget for RSA SecureID tokens, forcing us back to single factor certificate based auth for remote access. OUCH!!! Talk about one step forward and 5 steps back.
  • Everything harder to justify and subject to cuts. We’re even getting challenged on anti-virus software license renewals.
  • I am sure some items were missed, but in these dire circumstances, when people leave, the contract position is left empty, and cash is king - because nothing seems to be measured in terms of quality any longer, but more along the lines of cost!
  • security training and conferences
  • User information security awareness activities severely curtailed at my organization. The users in this case are the bank’s financial officers and their administrative staff. - Staff training - Slowing down of closing open audit items, including ‘High”
  • Training/travel budget
  • We are relying heavily on open-source right now.
  • No
  • External training non-existent - not even to pay for attending a SANS training course on a work study basis
  • subscriptions to organizations and training.
  • Available capex and opex funding is lower than normal, which means the budget is just being allocated to few projects. Otherwise, work is progressing for higher priorities.
  • Directly cutting personnel including the people doing the security checks

QUESTION #4: What tasks are you focusing on for automation? Has this changed due to the budget? (17/23 answered this question)

  • [I]dentity manag[e]ment and no
  • No changes Computerized provider order entry
  • Not much.
  • Pushing more value from our SIEM and IDS to automate manual things, that and finding other overlaps in technologies, turning on features we never used before, just basic optimization of what we’ve got, vs buying more point solutions ($$).
  • No automation tasks right now
  • log review, authorization controls; doing less because of staffing shortages
  • The same things that were automated before are being automated now…no big changes, although there is a need to look into other methods to automate tasks, in order that with less people, we can be more efficient.
  • Some of us are learning python to script the log review/reporting and implementing OSSEC
  • Money seems to be coming out of nowhere to improve security by agreeing to purchase more products
  • Our security program is in it’s infancy, and as such, we are just now developing a scanning program.
  • As we will not gain any staff we are automating as much as we can.
  • No. Log reporting
  • Improving end user processes as this will have greater impact on organizational productivity than focusing upon IT alone.
  • None.
  • High-volume highly manual tasks such as access provisioning.
  • Automating data-gathering for KPIs associated with IT security, Log analysis, Information Risk Awareness (improvements to an internally developed risk management process)
  • Incident detection (via extrusion monitoring). Nope.
  • [A]utomating everything possible. No changes.

QUESTION #5: For those tasks you are trying to automate, how are you prioritizing? (18/23 answered thia question)

Pretty interesting results, I’d say. Most of you are feeling *some* pinch from the economy, whether it’s in paring back people, technology, or training. A handful of you are not feeling much, if any, effect. Thanks to all who participated, I hope this is useful!

Information Security

The Security Hierarchy of Needs

March 15th, 2009

Welcome back, folks, for another episode of “Dave’s Security Soapbox”. This topic is one I’ve had mulling around in my mind for quite some time. It’s hugely subjective, so it’s virtually a guarantee that some people will vehemently disagree with my thoughts on this.

For those of you with a background in Psychology (or not) you’re probably familiar with a concept advanced by Abraham Maslow called “The Hierarchy of Needs”. This took the form of a pyramid split into several horizontal categories. The base of the triangle was the fundamental stuff - food, shelter, etc. The pinnacle of the pyramid was something called “self-actualization”, where we had infinite self-awareness and could recognize our innermost desires (the more transcendental ones).

I’m going to map out a fundamental hierarchy of needs in the infosec products space. I am headed out to RSA 2009 in a month or so (see the Events page for my presentation info), and my thoughts are all over the infosec vendorspace. The last two years I’ve gone, I’ve been spectacularly underwhelmed at the plethora of “me too!” and buzzword-laden product offerings that are just NOT technically innovative or exciting at all. And so blog I must.

Let’s start with the categories, and then I’ll explain my simple methodology. I actually used last year’s (2008) RSA Conference Guide as a reference just to make sure we’re all talking the same talk. The RSA guide categorized all the vendors on the Expo floor, and I’ve culled from that (with some condensation and modifications). Here goes:

  • Access Controls: Network/Host
  • Administrative Password Mgmt
  • Anti-Spam
  • Anti-malware (spyware & virus prevention/detection/eradication)
  • Application Security (code analysis)
  • Application Security (Web App Firewalls, etc)
  • Audit and compliance Tools
  • 2-factor Auth (biometrics, smart cards, tokens, etc)
  • Content filtering/mgmt
  • Database monitoring
  • Database encryption
  • Email encryption
  • Email security
  • Encryption/key mgmt
  • End-point Security solutions (NAC and such cruft)
  • Endpoint encryption
  • Network Firewalls
  • Host-based firewalls
  • Forensics solutions
  • ID mgmt
  • IM Security
  • DLP
  • IDS / IPS
  • Log Management
  • NBAD solutions
  • Patching and configuration management
  • Penetration testing and VA tools
  • Remote Access / VPN
  • Risk mgmt and analysis
  • SEM
  • SSO
  • Storage Security
  • Wireless security

Wow. Even with my extensive efforts at consolidation and simplification, that’s a fair-sized list. To be sure, you could wrangle this in a number of ways, too. For instance, you could consolidate all email and IM solutions into something like “Messaging security”. You could lump IDS/IPS/Firewall into “Network Security”. I didn’t want to OVER-simplify here, though, just to make sure the individual purpose of each category was obvious. So now let me explain my general methodology. I broke the hierarchy into four categories, which I’ll explain here:

  1. Fundamental security solutions: This is the “base” category that is essential to sound security in an enterprise. Without this, chances are you’re toast or soon will be.
  2. Important security solutions: These are “things you SHOULD have”. If you don’t have them, you may be able to get by, but you’re really not in that nebulous “best practices” area we love so much. You will also NOT be popular at security geek cocktail parties. Just saying.
  3. Enhancing security solutions: These are “things you COULD have”. These solutions can make routine tasks much easier, can simplify your life, and are great if you have budget money. In certain cases, you may have a very specific business need that warrants a point solution in this category, but in many cases these are things on your wish list, and maybe the things you sort of covet at the aforementioned cocktail parties when your compadre from down the street brags about HIS sweet new implementation.
  4. Holistic solutions: These are the “umbrella” solutions that overarch the rest and provide “glue” that links everything together. This is the tip of the pyramid, the most technically sophisticated solutions(and the most complicated, in many cases). They’re almost always unnecessary, but let you achieve very granular control over your security controls with more centralized reporting, correlation, and all that stuff that lets you REALLY smirk a bit at these mythical infosec cocktail parties I keep talking about.

A few things are not included at all. It’s tempting to argue that things like policies, configuration standards, processes (operational/administrative) and the like are all critical here, and they ARE. However, I think those are somewhat of an overlay alongside the entire pyramid, and so let’s assume that those are integral at every layer, in varying degrees. So without further ado, my Security Hierarchy of Needs:

Alright, now for the explanations and caveats. Starting at the bottom of the hierarchy, here are some additional insights that will help explain my reasoning:

Core fundamentals layer:

  • I don’t care what kind of anti-malware you use. Security people reading this may not even USE traditional anti-malware (I personally hate it), but think of the users. I know it hurts, but try. :)
  • Network firewalls, in some form or fashion, are just a must. You could argue that this falls into “access controls”, and I would agree as a macro-level category, but firewalls have enough individuality these days to warrant their own category, and I can’t imagine not having one. Sort of like my network infosec “wubby”, or security blanket.
  • IDS and IPS - I could care less which you use, really. However, you need eyes/ears on the network, and this fills that role. Whether you play the inline game or not, you need network intel and here you go.
  • Some of you will scream bias in “patching and config mgmt” since I work for a vendor in this space. Of course you’re right, but this ain’t my first rodeo, either, so I’m perfectly capable of being objective during this kind of analysis. I’ve been in the trenches a LONG time, and this one is critical. If you use WSUS for patching and Windows’ included Group Policy for config mgmt (or scripting for that matter), I don’t really care about that either. As an area of infosec, this one is hands-down a core fundamental.

Important solutions layer:

  • Spam can be used to trick users via phishing, etc. Gotta kill spam.
  • Code analysis? Damn right. It’s all code at the end of the day, folks - hardware has no brain. We need to start getting this drilled into our brains NOW - review code. Fix code. Repeat.
  • Encryption is, in many cases, the right answer. We’re not quite there yet, it’s expensive and tough to manage, but we need more of it. Just like code analysis tools, we need to get our arms around this and do it QUICKLY.
  • Pen testing and VA tools can tell you what’s f***ed before someone else finds it. If you’re not proactive, you’re reactive. Get proactive and start scanning and assessing yourself regularly.

Enhancing solutions layer:

  • Most platforms and such have password management sort-of built-in, so additional password mgmt really just adds a bit more functionality etc.
  • End-point tools and host-based firewalls (or HIDS for that matter) sound great in theory, but they are tough to manage and keep up with. Plus more overhead on remote systems can start to clog them.
  • Forensics wonks will likely pitch a fit about this category being where I placed it, but sorry. Most people don’t have the time or budget to really “do forensics”. For those of you that do, rock and roll. It’s great stuff, and can really help you get to the root of the most difficult infosec incidents. Most business owners don’t give two shits, though. Find it, fix it, get back in business. And this can be done 90% of the time sans forensics.
  • Wireless security I need to make a point on: this ONLY applies to wireless security PRODUCTS. Enabling and configuring inherent wireless security in WAPs and other gear is ESSENTIAL, and really falls under the fundamental category of configuration management. You MUST have strong wireless security, I’m just saying you can usually get what you need with the gear you’re using, as it’s typically built right in.
  • DLP? Ummmmm…..buzzword? If you do most of the other things right, you won’t need it. My main beef with this solution is its lack of maturity, it really does have promise and we DO need to prevent data leakage. But damn that’s one hell of an expensive enhancement to Regex.
  • Log mgmt is like wireless - you really should do it, I am just not sold on BUYING anything to do it. I’ve built homegrown solutions, they worked. This is a “nice to have”, without a doubt. You may really see a need for this one, and I could go along with moving this one down a rung in the hierarchy. Convince me.

Holistic solutions layer:

  • Identity management is the most nightmarish project many of us have ever been exposed to. I have candidly NEVER seen it done right, and there’s probably a plethora of reasons for that. Could it be amazing and enlightening if implemented and architected properly? Hell yes. But it’s just not practical for most enterprises.
  • SSO is in the same boat as ID mgmt, and some would argue it’s a sub-category of ID mgmt in fact. Same logic applies - can be a PITA, and most of us just don’t have the time etc.
  • SEM solutions can be an albatross or panacea, and sometimes both. I’ve used a lot of them, and I have seen a number of cases where these can be the ultimate tools to have and use. I’ve also seen cases where people were drowning trying to get it to work. But for my money, I’ll take SEM solutions as the best investment you can make for getting a good portion of your security house in order.
  • Risk management is 100% integral to our profession, especially those (like me) with a serious business mentality. In fact, if you DON’T do this, you won’t be relevant for long in this field (I’ve ranted about this before). But do you need a SOLUTION? I don’t think so, in most cases. So the moral of the story is risk management is required, risk management solutions are not.

So here’s the rub - I’m not bashing anything on this list. I work with a lot of vendors, I teach this stuff at SANS, I have architected solutions for my consulting clients that involved everything on this list. But if I were pressed to argue what solutions are more important than others in most cases, this is probably how the chips would fall. What say ye?

Information Security

A Bot by Any Other Name…

March 7th, 2009

So the Oak Ridge boys are at it again. No, not the terrible hillbilly group that sang “Elvira” whenever the hell THAT was, but the enterprising geeks at the Oak Ridge National Laboratory. And there’s probably women there, too. Probably. Anyhoo…

They’ve hatched a brilliant scheme to build a massive botnet that will defend US computers. Apparently, said botnet will be managed and controlled by a “hive mind”, and here’s where things start to get interesting: the system, called UNTAME (Ubiquitous Transient Autonomous Mission Entities) will “…be able to form groups, function autonomously and respond almost immediately.”

OK, I am a bit of a paranoid, sci-fi geek. I am totally thinking SKYNET here. Can’t help myself. These things will be able to make decisions on their own, replicate and regenerate! Even the project director, Joe Trien, admits that “…If we don’t put some boundaries on these cybots, they could turn against us. The potential is always there.”

This project is at least two years out, according to estimates. This really reminds me of the whole “Ethical Worm” debate we’ve had in security for years, though. While it sounds like a good idea on the surface (quick, self-replicating remediation and protection capabilities), I think most of us have come to the conclusion that anything self-replicating could be a nightmare. What if things break? What about “downstream liability” if the thing escapes our network? How do you shut it off? You know what they say about the best-laid plans of mice and men…

Full article @ FOX News here: http://www.foxnews.com/story/0,2933,505159,00.html

Information Security