How is that Assurance Evidence?

Not Quite Dead Yet

noreply@blogger.com (Chris) — Mon, 23 Jan 2012 17:31:00 +0000

Things are still extremely busy with day jobs, side projects and foster kids. However, I will be at ShmooCon 2012! So hit me up on twitter if you want to have some beers.

See you there!

Just So You Know I'm Not Dead

noreply@blogger.com (Chris) — Tue, 01 Nov 2011 14:39:00 +0000

Items I am working on:

Review of 800-30, Rev 1;
RedSpartan

So in the meantime, a guitar god: http://www.youtube.com/watch?v=hkz7wUg1L1o

Wim Remes for ISC(2) Board of Directors

noreply@blogger.com (Chris) — Wed, 31 Aug 2011 17:13:00 +0000

I support Wim Remes for ISC(2) Board of Directors. I agree with his vision for the organization and his views on infosec in general. If you do too, follow the directions on his page to have him placed on the ballot for election.

Do this soon as the deadline for him to submit is September 19th, 2011. In fact, do it by the 18th so that there is no confusion.

That is all.

Feds and Amazon Web Services

noreply@blogger.com (Chris) — Mon, 22 Aug 2011 16:00:00 +0000

Hi. I'm Chris and I'm an AWS addict. <Crowd>Hi Chris</Crowd>

That's right, I am using an EC2 as a development platform for RedSpartan as a code repository, wiki and issue tracker (in the form of a RedMine instance). I am also using a Windows instance to host the development and alpha instances of the tool itself. *gasp*

I am telling you this because I am totally confident in my ability to encrypt the sensitive information in the database and on the file system. I also feel that I have created an environment for my application to run where (if even Amazon were to fail at protecting my instance) that an attacker would have limited success in capturing any data.

I use AWS because the VM is mine to manage. I deploy patches. I install software. I configure the firewall. I take images when I want. When I want a restore, I get one. I want a reboot, the box is rebooted.

The downside: It is mine to screw up. But I do not fear because I have been managing servers for nearly 15 years.

I don't want this to end up sounding like a sales pitch for RedSpartan, my professional services or AWS. However, virtual machines, cloud and XaaS is the future of enterprise computing. As a result, I feel that applications need to be built in a robust manner. Does this mean that I spent extra time on reducing my vulnerability count? Yes. Does it mean that I scrapped many, many lines of code because I architected it incorrectly? Yes. Does it mean that I am a paranoid, crazy person? Perhaps.

The point I am trying to make is that you can put your data and applications anywhere (like AWS) but it still needs to be protected. As part of Amazon's recent announcement that they can comply with FISMA in their new government region, there is still significant work to ensure that data is protected. I don't know anything about the controls in place at Amazon, but I will say that nowhere is 800-53 mentioned in their press release or the baseline they expect to meet. They also mention SAS 70, which to my knowledge is being sunset in favor of SSAE 16. This tells me that Amazon is not wholly up to date on what is happening in the compliance space. Given that ITAR is mentioned 3 times, I think that this is more about ensuring that the government's data is in Northern Virginia or California (or both).

A friend of mine said that he recently worked on an authorization package that was not in the GovCloud region but that was hosted with Amazon. His words where something like: Amazon's crap is wired and their kung fu is strong. I believe him. But I would also not document controls for Amazon, I would mark them as inherited and put them on the hook via their own SSP. I expect by now that Amazon would have a standard SSP with the controls they are providing with all the usual things that go into an SSP. That way they aren't reinventing the wheel for each new Federal customer.

So I say: Cloud it up govies. But do it in a way that protects the government, citizens and whoever you are keeping files on.

My Take on 800-128 (Intentional Rhyming Attempt)

noreply@blogger.com (Chris) — Tue, 16 Aug 2011 15:21:00 +0000

I did not get a chance to read 800-128 during the draft phase, mainly because I was too busy. But also because I wasn't all that worried. I did however have one of the analyst I work with read it and he had some positive things to say. So if this comes across as not news to you or something akin to a 12 year old girl saying "Duh!", then please excuse me for just now catching up.

Pros (in no particular order):

A consolidated place for information on Configuration Management.
Control References - in section 2.3 there is a description of the activity to be performed and THEN the control reference.
The Appendices.
Very Nearly The Holy Grail of Federal IT Systems Compliance (keep reading).

Cons (also in no particular order):

The introduction of Security-Focused Configuration Management (SecCM).
Tries to make it an organizational problem with limited dealings when it pertains to system.
Limited to no mention of outsourced systems OR how to handle "cloud" environments.

This document contains how configuration management should be done in and around the Federal government. This has been needed for a long time, especially since many places do configuration management incorrectly and/or half-assed. Some of which rely on the 800-53 controls as their implementation guide. But the document does mention SDLC in the document with pointers to things like 800-64.

If you do not know what you are doing, or simply want some place to start, then 800-128 is for you. If you have a decent program or want some tips on how to improve it; I don't know that you'll find any of the answers that you seek in 800-128. It will not fix personality problems with co-workers, but there are some explicit recommendations that you could use as a bat to beat them with.

The key point that NIST is driving here is the SecCM concept. SP 800-128 is not "transforming" configuration management but (as the name implies) wants everything relating to configuration management to be security centric. This may conflict with those who believe that configuration management is all about making it easy for IT administrators and developers. Especially if the security and operations staff don't get along with each other. I think it would be best to continue selling it as a performance and efficiency enhancement, while reaping the rewards of better documentation and system configuration monitoring.

What you will find is some decent appendices that have templates for a Configuration Management Plan and a Security Impact Analysis. Two things that desperately need consistency between departments and agencies. Some people may find the work-flows in Appendix G somewhat helpful for visual learners. However, Appendix F is the least helpful in that it regurgitates everything we know about securing a system and points you to a number of the other 800-series documents.

You may remember from above that I mentioned that you may find the Holy Grail of Federal IT Systems Compliance in this document. No it is not, "The Definitive Guide on How to Establish an Authorization Boundary". Attachment 1 (part of the SIA template - not even in the Table of Contents) at the very end of 800-128 has 10 questions that ask whomever is filling out the SIA template to identify the significance of a change. I believe that it is a worksheet that concisely identifies whether a change is significant enough to require a re-authorization event. Which is kind of a big deal. This is in fact my version of trumpeting it from the mountain tops. I think that it will need to be customized to the individual agency or department that is using it. Also, PLEASE let me know if you have seen this gem before and I have just missed it.

Now for the bad news. The document is almost fanatical about the need for something to come from the organization (Section 3.1.1) as it should be. The problem is that with service purchases, outsourced systems and clouded systems, there really isn't a super way to have software run on those components for it to report back to the mother ship. This is the part where you say: "Chris, I can just upload my SCAP results at the end of the month". OK, fine you got me. Have your junior squirrels or security monitoring staff upload some properly formatted XML results every month or setup a scheduled job to do it for you. My experience is that sending that level of granularity to an agency or department leads to information overload OR having to track and approve many, many waivers and exceptions. That isn't to say that you shouldn't try. I would say that there may be pieces of what 800-128 puts on the organization that needs to be pushed to the system or that things that are the system's responsibility need to be addressed by the organization.

I think that it is also a little naive to expect that the SIA is going to be conducted in the manner described in Section 3.3.3 given the release cycle of some systems (especially those that are behind or late).

Lastly, it wouldn't be a NIST document if there weren't an allusion to the use of software tools to improve efficiency. This one is no exception. SCAP would be nothing without scanning and assessing tools, but tools are not going to fix the problem. Without a clearly defined policy -> procedure -> process -> document trail, then you are trying to row upstream on a quickly moving river. On larger systems, tools definitely need to be used. That doesn't mean that you need to stand up something separate from what operations is doing to manage the systems.

As always, 800-series documents are recommendations not requirements. Develop your processes in a way that works for where you are and build in tools and technology around it. But the 800-128 is very good at helping with the bulk of the work that Continuous Monitoring is trying to accomplish.

800-53 Appendix J - Privacy Controls

noreply@blogger.com (Chris) — Thu, 21 Jul 2011 15:18:00 +0000

I feel like I need to say something about the latest addition to my favorite document.

Redundant and unnecessary springs to mind. While new words may be used to talk about the same things, the bottom line is the same as it always is: limit what you collect and then protect it with in the budget constraints you have.

Below is the text of an email I have sent to a number of my customers (as they pay my opinion on such things).

Subject: NIST 800-53 Rev 4

NIST is projecting a release of an updated 800-53 in December. At this time, the only thing that is changing is the addition of Appendix J. Appendix J provide 23 new controls related privacy data protection.

After a quick review, I do not believe that we are in any danger of having to implement something new as far as technology. However, we may need to go through the exercise of updating our documentation to add these new controls (should decide to adopt them).

Attached is the draft of Appendix J for your review. Let me know if you have any questions.

-C

Of course, I attached the PDF for them - you can look at here: http://csrc.nist.gov/publications/drafts/800-53-Appdendix-J/IPDraft_800-53-privacy-appendix-J.pdf

I know that some organizations feel they need these new controls. The ones I work with are not those. If I am totally cynical about the whole thing; I think that this is a way for some people to check more boxes to say how awesome they are OR for someone to justify spending more money on technology that should already be in place.

Announcing RedSpartan

noreply@blogger.com (Chris) — Mon, 11 Apr 2011 13:17:00 +0000

Today a private alpha of RedSpartan is being made available to compliance and security professionals for review. RedSpartan has been built from the ground up, incorporating features and workflow to benefit audit and compliance teams struggling with tasking and geographical challenges.

RedSpartan is a platform from which an organization can assess (itself or another organization) with industry standard or internal control sets. RedSpartan will maintain the customer’s control set and test procedures. This allows organizations to have standard procedures for all team members, but provides the flexibility to add custom procedures as necessary. Teams can review all procedures for a control in a single view and write a compliance statement for the control and/or findings.

In RedSpartan, findings are tied to test steps, eliminating confusion about what needs to be done in order to satisfy remediation. RedSpartan has a standard set of several reports and formats. The reporting is designed so that new and custom formats and reports can be rapidly developed and deployed, however that feature will be available in the future.

Future features planned for RedSpartan include: allowing for uploading of results from tools such as Nessus, Lynis and our own testing scripts; incorporating role-based access to the features of the system; an archive function; plus other exciting plans on our roadmap.

We welcome any and all feedback via Twitter (@RedSpartan), our web site http://www.redspartan.com or email (support -@- redeyetek dot com)

The Biggest Problem

noreply@blogger.com (Chris) — Mon, 19 Jul 2010 19:04:00 +0000

By far, the biggest problem I run into during my time as an information security person is not: misconfigured firewalls, unencrypted USB drives or a poor risk management program. The biggest problem is communications.

I don’t know that I have the answer, but I will tell you that I get a lot of emails that I don’t care about and others that I probably do need to care about but aren’t written in a manner that is useful. I imagine that this guy has some interesting idea regarding email management. But that isn’t all.

It is all about knowing your audience. It sounds basic, I know, but don’t confuse basic with simple. Many people don’t totally understand things like FISMA, FIPS and the 800-series documents. Even those that do may interpret different ideas and concepts in a conflicting manner.

We deal in a complicated and ever-changing space, so do us all a favor and maintain a project glossary and acronym list. Use your snazzy Document/Content management systems or MediaWiki.

I also like to provide standard process documents that back up a project plan. A project plan is telling for some, but here again is an opportunity for failure. One-line entries in a spreadsheet or MS-Project are prone to misinterpretation given their short nature. My process documents are not tasks, but an explanation of activities. It is in plain speak usually one to two paragraphs that talk about what is going to happen during a phase of the project (not necessarily tied to 800-37 or SDLC frameworks). Especially when it comes to short engagements, it is difficult to spin up a lot of collateral or spend time with education.

Learn how to write. I know I’m not the best writer, but damn. Spell check is not a fix for the “they’re/their/there” issue. Some of this can solved with taking an extra two minutes to read your writing again.

Lastly (and something that I intend to try out in soon), is to spend the time to copy and paste. I am one of those people who think I impress someone with my ability to reference an appendix or section of a document. No more. I estimate that 90% of the time, the recipient(s) of my reference didn’t bother to go look at it. Therefore, they still don’t know what you’re talking about, but worse you think that they do. It also gives you an opportunity to apply to explain the relevance or your interpretation of the selection.

This is only some small hints, but sometimes the smallest gains in productivity are the best (because they are the most annoying).

Numbers and Metrics

noreply@blogger.com (Chris) — Thu, 10 Jun 2010 17:13:00 +0000

Before I get to an analysis of FISMA reforms and their potential impacts, I wanted touch on something that has been biting my ass for a little while.

I get asked to justify my existence and what I provide as a return on investment. As part of that, I have tried to quantify the value of an information security or risk management program. If this were a normal blog, I would launch into a diatribe replete with all the necessary management buzz words, catch phrases and witty clichés. This is not a normal blog, so if that is what you are looking for then you can move on.

Much of the time information system risk management is based on existing risk assessment and monitoring frameworks, either insurance or financial or whatever. My opinion is that those don't work. Mainly, because those metrics are difficult for everyone to understand and they are basically rigged out to screw a customer. In the information systems world, the risk management framework needs to HELP a customer. I could be totally wrong though, but these frameworks are developed by corporations with a profit motive (not that there's anything wrong with that).

The other weak link in the chain (for me) is that even for quantitative frameworks, there is still room to fudge the numbers by a single person or data input. When you are assessing a mortgage for risk there is a history for a person, history for the house and the general climate of the market. All of which let us down in the recent past, due to securitization, greed and complicated schemes to make it all look good. There isn't a lot of room for that in the information security world.

I know what also isn't working - technical numbers. Number of viruses caught by AV, IDS true/false positive rates, percentage of environment patched. These don't work because MBA can see a 90% as pretty good. The problem with this is that even when you are at 100% there is still an unknown number of zero-day exploits in deployed software and there is still the element of human failures (lack of knowledge, misconfiguration and outright theft).

This wasn't supposed to sound all doom and gloom though. I am pointing out that somehow we as a community are doing something wrong. But please comment if you have had success in this arena. I have not seen it yet.

My idea:

I have been a fan of Eli Goldratt and the Theory of Constraints for about 10 years now, and I would love to figure out a way to apply ToC to information system risk management. You will notice I didn't say information security because a holistic risk management program includes operational and security risks.

For a couple of reasons: it is flexible for a dynamic environment, it depends on the improvement processes and the measurements for success are easy to understand.

Where's my white board?

Lame Post

noreply@blogger.com (Chris) — Fri, 04 Jun 2010 20:26:00 +0000

This week's post is a pointer to my interview on the Southern Fried Security podcast.

http://www.southernfriedsecurity.com/the-episodes/episode-16---av-is-dead

Thanks for reading and listening.

Happy Memorial Day!

noreply@blogger.com (Chris) — Mon, 31 May 2010 11:18:00 +0000

In honor of those who have and do serve our country, Happy Memorial Day!

A special shout out to Grandpa Burton who served in Europe (where he earned a purple heart during the Battle of the Bulge) and Grandpa Baker who served in the Pacific.

To my Dad and uncle who served during the Vietnam era, Semper Fi!

Last but not least my friends Mike Smith-Gulf War 1 (from EOUSA), Mike Smith-Afghanistan (from Guerilla CISO fame) and Ferguson, thanks for your more recent service.

On Greed and Complianciness

noreply@blogger.com (Chris) — Tue, 25 May 2010 13:09:00 +0000

Disclaimer: This post is not inspired by any past or present events in my work or personal life. The opinions expressed here are mine and not necessarily those of any of my employers, customers, vendors or organizations with which I affiliate.

As the Gulf coast becomes another environmental disaster and still recovering from the financial meltdown, I can't help but think about the parallels between having a well run information security program and compliance. You must know by now, I am an advocate of the work NIST has done as a result of FISMA. This has led to the many 800-series documents which helped many organizations, despite what the haters may say. We need compliance and compliance frameworks, if we don't then nothing will happen.

BP was not required to have the secondary piece of equipment, so they didn't put it in. Now look what happened. Wall Street gambles with people's mortgages and livelihoods, and the taxpayers (in the form of the Federal Reserve and Bailouts) have financed the losses.

In the same vein, why would an agency or department spend taxpayer money on security when they aren't required to? Especially since there is a deficit and a push to contain costs. They wouldn't. Congress had to mandate it.

I'm not trying to make a political statement, I am saying that without compliance programs and frameworks - a company would do nothing. Without the threat of fines from compliance or public relations disasters, a corporation has no incentive to do ... anything.

So here again, let us not confuse failures because a company practices complianciness. We should also not be surprised that an organization chooses to take the path of least resistance and doesn't put resources towards a real information protection program.

Attention Cloud Fanatics

noreply@blogger.com (Chris) — Fri, 07 May 2010 21:01:00 +0000

The Bureau of Engraving and Printing web site is back up. I am not sure when it came up but I thought I would conduct my own uninformed lessons learned.

My initial impressions: The cloud has the same problems that other platforms do.

I am not a cloud apologist, but I think that we can all agree that application security sucks as a general rule and not enough people are listening to OWASP.

So while I would love to throw "cloud" or outsourced services under the bus, this is an application vulnerability that could happen to any site. It is a "failure to assess" as opposed to a "failure to communicate".

There is a decent wrap-up of the whole thing here: http://www.federalnewsradio.com/index.php?nid=19&sid=1951253 My problem with that story is the last paragraphs that talk about staying patched and using anti-malware software. But at least he agrees that it isn't necessarily cloud related.

The bottom line for me is that "it's the basics, stupid". Cloud, not cloud, embedded, virtualized, whatever. It all comes back to the same types of problems and there is no easy fix.

This Week in Gov't Computing

noreply@blogger.com (Chris) — Tue, 04 May 2010 21:31:00 +0000

And by this week I mean today, yesterday and part of last week.

It has been exciting though. Agency CIOs will now be required to report to OMB via CyberScope by November 15th. This is all laid out in Memoranda 10-15. My take away: Significant weaknesses don't need to be reported. WTF is that? You have to maintain it on file of course, so that you can provide it upon request.

CIOs are going to report the following:

Inventory
Systems and Services
Hardware
Software
External Connections
Security Training and
Identity Management and Access

That's super, right? There's instructions available here. Eventually, Vivek and Howard want it all in an Excel spreadsheet or XML format and then uploaded. You'll need to submit it monthly starting in January 2011. Sounds to me like someone has bought into the SANS Critical Consensus Whatever. But we know how I feel about that one already.

IGs will also need to report through the old system but on this set of categories:

Certification and Accreditation
Configuration Management
Security Incident Management
Security Training
Remediation/Plans of Actions and Milestones
Remote Access
Identity Management
Continuous Monitoring
Contractor Oversight
Contingency Planning

I'm not saying that the old process didn't need to be overhauled, but here again the Feds are moving away from a risk-based approach to control monitoring. Bejtlich seems to agree.

In other news, my Dad's agency (Bureau of Engraving and Printing) has had their web site HACKED! OMFG!

Oh wait, not so much. More on it at the Register and the AVG blog. Most importantly, Dad doesn't work on the external web site or in IT for that matter.

The first thing to consider is that the BEP external web site probably got a Low baseline assigned to it. It has also been reported in the Register article that it may be related to the Network Solutions Wordpress hacks of last month. Could very well be, but let us remember that someone should have run a pen test. If they did run a pen test, well then may be its time for a new testing vendor. Panda gives a detailed breakdown.

This is the kind of thing that doesn't inspire confidence in the government's ability to protect information. And while there isn't any data leakage or loss from the site itself, the A portion of CIA has fallen down severely. The web site is still off line as of May 4th, 2010 at 21:45 GMT.

Lastly, there is a new GAO report out on the Federal Housing Finance Agency say that the info sec controls could be better. This is important because FHFA is the agency that: "... regulates Fannie Mae, Freddie Mac and the 12 Federal Home Loan Banks." So that's what's happening there.

Missing the Point ... Again.

noreply@blogger.com (Chris) — Mon, 12 Apr 2010 20:41:00 +0000

There has been a lot of who-ha (technical term) going around on the changes to Information Security in the Federal government. As the title suggests, there are many, many pundits and "experts" who proclaimed FISMA as a failure and needs an overhaul. It is my opinion that very little will actually change. Why you ask?

Institutional Momentum.

Like most things in the government, the original idea came from DoD and the Intel community. In this way, Certification and Accreditation could be a point in time event because they were running mainframes with hard wired terminals. So things did not change all that often. Systems evolved, web applications were developed, cloud computing, buzz word du jour, blah blah and suddenly the process is broken.

Did you know that certification is only mentioned once in FISMA? And not even the certification that we think of, it concerns a certification authority for digital signatures. Congress did not force the Certification and Accreditation process onto the Executive. If we jump into our way-back machine you may recall a post where I said that FISMA is about risk management. Continuous monitoring and vulnerability management were part of this vernacular from the start. FISMA was perverted into a checklist / table top exercise to keep costs and schedule under control, which is totally permissible if you accept the risk. Some of the feds simply were not ready to implement the NIST recommendations. Some still are not.

You may also know that a few weeks back, SP 800-37 Rev 1 went final. It seems that it has taken just over seven years, but the government produced meaningful recommendations to create a process to manage risk. With this document and the upcoming SP 800-39, we finally move in the direction of strategic risk management. While I have only taken a cursory look at the bills on the Hill, my understanding that there is little in the way of increasing the government’s ability to respond to incidents, perform practical contingency and business continuity exercises or enforce more extensive testing methodologies. I believe this has to do with vendor influences, but I could be completely wrong in my assumptions.

FISMA has done exactly what it was intended to do. Those who didn't/don't/can't understand security, vilified it from the start. Which I felt was an attempt at a self fulfilling prophecy. Lest we forget where we were in 2002. Very little was done beyond a firewall on the perimeter and some A/V on the desktops. Because of FISMA and the thousands (perhaps millions) of findings written, many more technologies have been deployed such as web application testing and intrusion detection. We all understand that we can and should do more, but that is all security programs. This one just happens to be open to regular public criticism. Outside critics should consider the 800 series documents for what they are, guidance for the creation of a solid security program and not as simply a compliance effort.

It would have been better if the new legislation simply said "Do what we already told you to do, but ‘this time with four part harmony and feeling’". Ending with funding for agency staff education and time off to go learn what information system risk management really is.

The New 800-37

noreply@blogger.com (Chris) — Mon, 22 Feb 2010 21:16:00 +0000

Attention everyone: the 800-37 Rev 1 has gone final! I think I may re-cap the changes in this forum. We'll see if that actually comes together.

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

Out.

ShmooCon

noreply@blogger.com (Chris) — Thu, 04 Feb 2010 20:58:00 +0000

I will be at ShmooCon February 5th until the 7th. By luck, I managed to get a room at the last minute.

Hit me on twitter at http://twitter.com/cyberhiker during the event. Even if you just want a snowfall report.

Technology Death Pronouncment

noreply@blogger.com (Chris) — Mon, 04 Jan 2010 18:10:00 +0000

I haven't seen much of the Firewalls, Anti-Virus and IDS are Dead technologies recently, Mind you I have been extremely busy with other things of late.

The short version is that I am ready to proclaim that nothing is dead. That's right. No matter how hard we try to get away from mainframes or Windows NT or whatever. Most of us have to deal with things on a regular basis. So get over it.

What should be dead is calling different technologies dead. Especially since there will always be a reason to use whatever "it" is, even if the reason is a bad one.

There are couple reasons for this. The finance guys don't have a lot of patience for needing to spend $1 Million at the beginning of the year and then reading in *Business* magazine by *expert* that *technology* is now on a slab.

The reality of it is that the uninitiated gets upset. It also upsets me. But for different reasons. Here are a group of people (security staff) in a company who have probably fought for months to bring something in, get it installed and operating. Only for some blow hole to come through and make an uninformed opinion about everyone's environment.

The aforementioned blow hole comes with credibility, because they are published. The people on staff probably not. I don't hate the blow hole though because they are trying to sell magazines and announcing the death of whatever sells X publication.

It all comes down to profiling the risks to your organization. If you are a decision maker, take advice from industry rags with a grain of salt. If you are in the trenches, be sure that your business cases are tight and the deciders know what the technology does and the risks it is mitigating.

That is all.

Which brings me to tonight's word: Complianciness

noreply@blogger.com (Chris) — Thu, 17 Sep 2009 17:47:00 +0000

Much like the way that Stephen Colbert uses Truthiness, where it is not the actual truth but “the quality of preferring concepts or facts one wishes to be true, rather than concepts of facts known to be true”. Complianciness is not actually compliance, but that you want to believe that you are compliant rather than actually being compliant.

This word evolved from a conversation with a number of highly regarded professionals (Mike Smith, Dan Philpott and Graydon McKee), with shout-outs to Chris Hoff and Anton Chuvakin for a twitter exchange around measurements (I believe this post is worth 286,497 Chuvakins).

And here (I believe) is one of its best examples:

Recently, Bob Carr (CEO of Heartland Payment Systems) gave a podcast interview to Bill Brenner at CSO Online. During this interview, Carr basically threw his Qualified Security Assessors (QSA) under the bus. He had equated what the QSA is responsible for doing (measuring Heartland against the PCI controls) for actual secure operations. There are two sides to this story I am sure, however I like to think of PCI-DSS as a “tech heavy” control set. To me this means that the controls are very focused on securing the technology but that it could still be maintained or operated poorly. That also means, that the QSA is focused on a very specific set of controls, not on Information System Risk Management (although it does mandate an annual risk assessment).

Carr asserts that the QSA assessments were not helpful for the years that he had to pay for it. I would argue that they were helpful because it showed Visa and Mastercard that Heartland had implemented a minimum set of controls to protect some information for Visa and Mastercard.

Where's the complianciness? Heartland Payment Systems – based on my research of the situation Heartland may have been PCI compliant at the point in time that they were assessed. It could be that security was a little more lax when the assessors were not inbound to conduct testing. It also might have been that a very elaborate show was put on for the assessors and they were not actually compliant, but perhaps practicing complianciness.

Question from the Audience: I thought you only talked about FISMA, where is the complianciness there?

A: Thank you random voice in my head.

It is rampant. FISMA / OMB / NIST Guidance all used come back to one thing, Information System Risk Management. The process of identifying risks to your mission or system and then applying a specific set of policies and controls to mitigate those risks. What has evolved from this, and I only have anecdotal evidence / hearsay to back this up, is that integrators, developers and operators are being told to simply follow NIST guidance. When that is entirely not possible without making some decisions by the customer.

NIST guidance is there to provide options and support. It can lay out things to consider and questions you should be asking yourself. The policies, procedures and processes that are carried out on an information system must be clearly defined at the beginning of the design process by being built into the design requirements.

I feel like now is the best time to mention these ideas because many organization in the government are going to be reviewing NIST 800-53 Rev 3, and having to make some decisions about what their policies are going to be for the next couple of years. My response is Choose Compliance not Complianciness.

Telling a vendor to go look at NIST and build it, will only get you what the vendor is willing to provide by shoehorning the solution into the controls. I'll elaborate. Vendor will read the controls. Vendor will either write the SSP or provide input to the Self Assessment. Those result will be their interpretation of the least effort required by that control. As the federal customer, you will believe that they have implemented that control to the strength that you believe it should be implemented. You have therefore practiced complianciness, at least until the auditor or assessor comes in and tells you what is actually happening (you hope). Because the auditor could in fact perceive the controls to be something entirely different altogether.

If you are part of a government agency, you want to provide a policy that can be based on 800-53 but you need to answer the questions it asks.

And that's the word.

Disturbing Trend

noreply@blogger.com (Chris) — Wed, 17 Jun 2009 00:07:00 +0000

I don't mean to be an alarmist or whatever. But that's how newspapers get sold and stations get ratings. What is this mystical issue? The answer is Control Implementation Prioritization.

Way back in February 2009 we were greeted with the Consensus Audit Guidelines (CAG). I personally do not care for CAG. Some people will get their controls implemented faster, better, cheaper. At a minimum, the guidelines are misleading since it had little to do with actual auditing or system security testing.

At the beginning of May, they revised CAG into 20 Critical Security Controls (CSC). Well at least now, there is some truth in the title. They are sold to us as controls that every system should implement. Well ... thanks. Let's take a quick look then.

Ahhh. Ok. So where is the part about laying down a strategy or developing an initial policy that needs to be followed. Its not there. Where is the part about strength and cost of the control implementation as measured against the risk. I couldn't find that either.

Apparently, that doesn't matter anymore. It is clear from the beginning that the focus of CSC is not about system-specific risk analysis anymore. So that is that, but then in Appendix D of the 800-53 Rev 3, Final Public Draft. What do my eyes find, CONTROL PRIORITIZATION. On a scale of 1 to 3 and a 0 for unspecified.

Now for the meat - why is this bad. Its bad because management types will focus on the number 1. "I have to do these controls first, because NIST told me so". Or "I have money for the top 20 then I will deal with the rest".

It has been proven time and time again security comes from determining risk and implementing controls comensurate with that risk. Then reassessing that risk and control effectiveness over time using adequate metrics. Plan for the worst with contingency and incident handling plans. Et cetera.

Implementation of the CSC will not make you safer, it will make the vendor richer. A total soup-to-nuts program is still the only way from my opinion. This would include selecting controls that you deem necessary.

I haven't died ...

noreply@blogger.com (Chris) — Tue, 19 May 2009 14:27:00 +0000

... I am just extremely busy. Please don't remove me from your RSS feed just yet.

In the interim, you can check me out at:
http://blog.marcusjcarey.com/2009/04/that-security-show-news-segment-concept.html

http://blog.marcusjcarey.com/2009/04/that-security-show-sampler.html

Random thoughts:

The ICE Act isn't going to make us more secure;
Mowing the lawn sucks;
I really like teaching at the Potomac Forum;
I am working on a concept/paper that I am calling Big Risk and;
I am also working a compliance framework to help manage security and compliance testing.

That is all.

Embedded Compliance

noreply@blogger.com (Chris) — Fri, 10 Apr 2009 19:45:00 +0000

I was recently using the twitter machine when someone asked me how I would develop requirements and the subsequent test cases for embedded devices. Beyond the fact that I needed more than 140 characters to answer, I found the question simultaneously amusing and befuddling. So this post is the result of that initial query.

We know that embedded devices will not have all the controls that even something like Windows is capable of meeting. Windows has a difficult time trying to meet a FIPS 199 categorization of moderate. Therefore, these devices put us (me) into a quandary. The podcast Pauldotcom.com routinely talks about pen testing exploits that involved using an embedded device as a launch point for more sinister attacks. But the devices will never have the security controls that full blown operating systems and applications are capable of implementing.

We also know that these types of devices have striped down versions of things we already know and love, like ... TCP stacks and ... file systems. But the tools that assessors or testers use with servers, web sites and routers do not work (at all) or unreliably (at best).

So here we have devices that are in the system boundary and processing data. Prevalent security researchers have already demonstrated the issues with them.

Obviously, they need to be tested; they need controls and protections. But how to test while collecting this mysterious assurance evidence. The answer is the dreaded manual test case. Sitting down with your refrigerator or microwave with your requirements (let's say its an agency tailored 800-53). Sit with the vendor or poor sap who has been tagged to "be in charge" to walk through the system with you as you develop the test steps. You are not retrieving the results or collecting evidence yet. This is merely to work out a repeatable process by which others can use to re-test later.

You now want to ask me: "what about requirements that I can't develop test steps?" So a control is not in place no matter what. This is still a requirement. It just means that you don't have to test for it because it has already failed. But you will need to leave a spot in the Security Assessment procedures that says "I interviewed and the vendor/system could not provide evidence that this control could be satisfied." OR "Review of manuals and system documentation revealed that the system does not implement the control" Fail. It does not mean that it is Not Applicable, because it is still a requirement.

What about gathering proof that the control is actually in place? This is what I think the real question is; the answer is that it depends. If you are going through a terminal, then you can capture the session to a text file. If it can be remote controlled through something like VNC or RDP, then you could take a screen movie. I found this software today which they claim you can embed into Word or PDF.

But then there are those that there is no remote screen or remote terminal. All we have is a generic interface on the device itself. Well I don't know what to tell you there except camera. Oh yes. The dreaded video camera on a tripod. You will need waivers and exemptions and all kinds of paperwork. But it is really the only way to capture the test procedure if that's the level of assurance required. That's why I left it for last, because it is most unpleasant. This would also fall in the category of "evidence available upon request".

Hopefully, a detailed procedure is all you need. Here is a sample of what I would envision a test of account lockout (AC-7) to look like (but it is lacking my usual pretty formatting):

Step 1: Log in using normal interface with a valid user account and password combination.
Expected Result: Log in successful

Step 2: Log out and attempt to log in using a valid user account and invalid password combination.
Expected Result: Log in unsuccessful

Step 3: Re-attempt Step 2 until .
Expected Result: Log in unsuccessful

Step 4: Re-attempt Step 1
Expected Result: Log in unsuccessful

Step 5: Wait for minutes (Only if not unlimited) and repeat Step 1
Expected Result: Log in successful

My typical reaction is to stop a procedure once something has failed. Or to have dependencies in the test steps to limit the number of procedures I have to manage.

So I don't know if I answered the original question, I feel better for putting at least something out there.

To Pen Test or not to Pen Test .. that is the question.

noreply@blogger.com (Chris) — Tue, 07 Apr 2009 17:28:00 +0000

I gave a Fire Talk at ShmooCon. I had hoped to convey that the way Federal agencies have been conducting their security assessments, has been flawed (at best) or wrong. I was asked a simple question "What should we do to fix it?" I gave a stock answer like document test cases better and spend more time and money on the assessment in general. It was a blow off but it was the best I could come up with while simultaneously being scared sh**less.

Then, I also was fortunate enough to be an instructor with the Potomac Forum at their Certification Accreditation Workshop with Graydon McKee and Dan Phillpott. It was truly awesome and glorious two days, but I digress. I was in the middle of a diatribe about how to assess a Federal system under the current NIST guidance and FISMA. I got to a part where I started talking about running a penetration test on the system before the accreditation/authorization to operate. Then another question "Do we NEED to run a pen test?" To which I responded ... "it depends".

Given the money and the time I would have any system I worked on penetration tested. I spent a few minutes trying to find what I mean when I say "pen test". I found it on this site, but I have it for you here:

Penetration test - A test of a network's vulnerabilities by having an authorized individual actually attempt to break into the network. The tester may undertake several methods, workarounds and "hacks" to gain entry, often initially getting through to one seemingly harmless section, and from there, attacking more sensitive areas of the network.

Who wouldn't want that? I would also add to this definition that the vulnerability is actually exploited and that evidence of the exploit it captured. Because then you have actually tested something. Running a tool and saying something like "conditions are favorable for a successful exploitation of" ... blah blah blah, is not a penetration test. That is a vulnerability assessment.

The reality is that most systems should be having vulnerability assessments done monthly, if not more frequently. Its not policy, but that's my opinion. Penetration test annually, or after substantial changes to the architecture.

Excuse 1: It Expensive.
Response: So is loosing your data.

According to a recent study (that I am currently unable to find - if you have a link then please comment), it could cost something like $200 per customer to restore their good standing. A decent test by a rock star tester is pricey. If we use this $200 number. Well - how many customers are using the system? Times Bad PR + Sleepless nights + Incident Response Services = a crap load more than the Pen Test.

Excuse 2: They could break our shhhh ... stuff
Response: We'll schedule downtime.

Most pen testers love pen testing. They also like money. Most will probably work with you to sacrifice a Saturday or Sunday evening. For one or both of these reasons. The other reality of this statement is that the person generating this excuse could be afraid of what is found. Ignorance is not bliss and obscurity is not security, the attacker will find weaknesses in the system. Get over the pride and let's just fix it.

Excuse 3: Our Coders / Developers are awesome
Response: Awesome people still make mistakes

I don't presume that most of the people who would read this trust a Bank carte blanch to handle your finances. You probably reconcile your check book, make sure that your online banking bills do, in fact, get paid, etc. Humans are not error-free neither is your code or system design. New vulnerabilities are found every day in software that we all use.

Excuse 4: We don't have time before the system needs to be live
Response: Get one after the system is live

The attackers will be working on your system from the word go. You will be required to defend it. Return to reasoning for excuse 2.

Excuse 5: Nobody wants our data
Response: You don't have a competitor?

Competitor is a wide range of possibilities. The Federal government has not just competition but real enemies. It could be another nation, terrorist or garden variety kook. If you aren't just putting information on the Internet, then clearly it requires protecting. Also, an attacker has time. Conceivably, they are motivated and they want what you have. They will spend hours, days or years working on your system and basically you need a way to outlast them.

Boss: Ok, I'm in. What's next?
You: Ahhh, yeah. I'll send you an email in the morning.

When in fact your response should have been: We are going to test everything. The guys we are bringing in can:

Attempt compromise from the Internet;
Attempt compromise from the inside (insider threat and/or accidents);
Social Engineer our employees and service providers (that's right I said it);
War-dial, war-drive, war-walk, war-unicycle through and around our facilities to identify unknown network entry points;
Leave USB thumb drives in the parking lot or FedEx DVDs or CDs to insiders;
(Please Comment to add more)

You may not need to do all of this each time, but it is my opinion that every organization should be going through most of these exercises on a regular basis. While they don't all fit the definition of a penetration test, these services can generally be provided by the same firm. You won't find anything in FISMA or NIST or OMB that says: "Thou shalt get a pen test", but the 800-42 says its a good idea.

So go get a pen test .. now.

More Information

noreply@blogger.com (Chris) — Fri, 13 Mar 2009 12:51:00 +0000

There is more detailed information on the Norm Coleman data breach here:

http://www.politico.com/news/stories/0309/19946.html

and here: http://butyoureagirl.com/

Oh the Hypocrisy

noreply@blogger.com (Chris) — Fri, 13 Mar 2009 11:51:00 +0000

Norm Coleman. He is the guy that is currently locked in a battle with Al Franken for Minnesota's US Senator. Setting personal feelings aside (Go Al!) Norm is truly ah ... not good.

You may remember my post from July of 2007 where Norm sponsored legislation on called the Federal Agency Data Breach Protection Act. The short version is that the bill didn't even make it to committee, so whatever. The best part of the bill text is this:

(A) a requirement for timely notice to be provided to those individuals whose sensitive personal information could be compromised as a result of such breach, except no notice shall be required if the breach does not create a reasonable risk of identity theft, fraud, or other unlawful conduct regarding such individual;

Today, I find out that his campaign is responsible for disclosure of thousands of donor records. Based on what I am reading on Talking Points Memo, the campaign didn't tell anyone that their records may have been divulged and the site wasn't properly secured.

Way to go Norm! You should totally be a senator again. I am glad that you understand the issues that represent.