How is that Assurance Evidence?

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.

The CAG

noreply@blogger.com (Chris) — Wed, 25 Feb 2009 04:56:00 +0000

Otherwise known as the Consensus Audit Guidelines.

In summary: Do everything we've been telling you to do. Identify -> Assess -> Secure -> Monitor -> Repeat.

See I just saved you two hours of reading.

But seriously, I suppose my main objection (from a very cursory review) is that now the technical controls that have generally been assessed using automated tools, will now be weighted more heavily than those which could conceivably be just as important.

Which is why we have (drum roll please ...) Risk Assessments. So that intelligent humans can decide for themselves which controls are more important than others in their environment.

Taking a step back, FIPS 199 (pdf) asks you to look to the 800-60. In the 800-60 (pdf), there is a lot of discussion around deciding what type of data you are processing, how sensitive is it, whose allowed to see it, who is isn't, etc. From that you are supposed to be able to extract a mystical level of concern for your data (Low, Moderate and High). In my career, I have only personally ever seen one (1) High system and that was for availability. The rest if you must know were/are Moderates.

As the auditor for the High system, we heavily weighted the Incident Response and Contingency Planning controls. We even had the authorizing authority and certification authority say they didn't want to *really* impose the High controls for most of the Technical family (gasp!). We call this a risk based decision. The risks for them were purely from a "keep the damn thing up for the love of all that is holy and good" perspective. But this isn't what I wanted to talk about, I think...

These boiled down "critical controls" are a dangerous thing, in my opinion. Anyone who has been put in a capacity to use/implement the guidelines, I imagine is having similar reactions. Because (again!) there is nothing new here. Now with more confusion because they are guidelines, like all the 800-series documents are guidelines.

Perhaps I will do a more detailed analysis and comment. For now, I find myself agitated and tired.

And they used the word "cyber" too much, MS-Word and OpenOffice don't even think it is a word.

This Week in Privacy

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

This week has seen some movement in the privacy area. This is not something I generally focus on, but since it has come into the Federal area on more than a few occasions; I thought I would say something.

First - Did you know that the word "privacy" is used 7 times in the FISMA law? Once to define confidentiality, once to reference the Privacy Act of 1974 and the other five times to talk about the Information Security and Privacy Advisory Board. This is a group that gets together 3-4 times a year and does what I would describe as "things". Its true. See for your self.

With that in mind, I will start off by saying that Facebook decided that they would update their Terms of Service. The new terms said that they could do whatever they wanted, whenever they wanted, with information that they collected. After some outrage from the intertubes, along with some people who abandoned their accounts, they have reversed their decision for now.

In other news, the Federal Trade Commission issued a report about targetted online advertising that basically said that companies should do better than they are now. Blah Blah Blah. That lead to other people suddenly caring and can a congressman that said more legislation is on the way.

Lastly, we get a gem from the Department of Homeland Security who issued a report about their keeping information private on their own systems and this report includes recommendations. This is where I felt I needed to say something.

DHS? The Department of Homeland Security is worried about keeping privacy information private? Also, there isn't anything NEW in this report! The recommendations are already in OMB memos and NIST docs. Don't they have a policy or what? Damnit.

Guerilla CISO can haz good slide show

noreply@blogger.com (Chris) — Fri, 13 Feb 2009 17:09:00 +0000

I just got a chance to review of a slide show that rybolov and others have obviously toiled over for quite some time. I did have some comments on it though. The link to the slide show is:

http://www.guerilla-ciso.com/archives/699

And my comments are on the site, and pasted here for your convenience:

I found the slides to be very good, I especially liked the scenarios.

I will be making changes to some of the semantics. Where it says that a certifier is finding risks, they in fact don’t. They discover findings. Those findings could be policy violations, evidence of policy violations or general system architecture weaknesses.

For instance, when I was a certification agent I did not list out all the patches they did not have installed. This is evidence that a patch management program is ineffective (depending on the date that a patch was released and that the SSP says that it is an implemented control).

The assignment of risk would be left up to the system owner, the certifier (a role that is disappearing in 800-37 Rev 1) or the AO. They would do this by going through an 800-30 exercise. They would start with the security assessment findings and then assign likelihood and impact ratings. This is also presuming that there is even a threat vector.

Let me know if you had a different interpretation or if I missed something.

I want to be clear here, that the community is in desperate need of more materials like this. There a ton of people who do this everyday who would watch this and it would be news to them.

Also, it is better if you listen to AC/DC's Hells Bells or any Metallica song while you read the slides.

Federal Gov hearts Cloud Computing (maybe)

noreply@blogger.com (Chris) — Mon, 09 Feb 2009 19:22:00 +0000

And by maybe, I mean if the new Obama pick for the new E-Gov person is confirmed.

I am a regular reader of Christofer Hoff over at Rational Suvivability and have been convinced that Cloud Computing is almost as evil as Dick Cheney.

Which is why this article on Obama's pick for E-Gov chief has me more than a little worried. The article spends a few paragraphs near the end talking about moving information "into the Cloud".

Cloud Computing is not a good idea, unless the government can build its own Cloud. This would involve the entire government knowing who owns and operates the infrastructure (probably GSA). In a perfect world, it would be like the ultimate General Support System (GSS, see the 800-37 [pdf]). All the agencies would sign MOUs and SLAs. They would use common APIs and there would be coding standards. Regular security checks and web application assessments. Oh the glory of it all!

But this isn't what will happen, one or many agencies will get pissed, take their ball and go home. They'll stand up their own solutions with the help of a prime and 500 sub contractors.

A single infrastructure would help some of the initiatives that are underway. Like Trusted Internet Connections, enforcement of policies on end point systems, encrypted off-site backups, IPv6, among others.

So that's something, but the risk is not worth the reward. A single infrastructure means that the whole government could be out when a targeted attack is underway. Or that a simple misconfiguration could lead to what Google faced with its badware miscategorization. How to design to be redundant and available? Would there need to be one for classified and unclassified? Who's going to support incidents? All the usual questions that go along with a shared infrastructure.

So I don't know, I would love to put applications onto a common supportable infrastructure and have the government save a crap load of money. On the other hand, doing it correctly will take years or decades to implement and there is no guarantee that everyone will be on board.

But to even get started, the current government guidance and regulations aren't clear on the best ways to execute a cloud implementation. The new 800-37 was supposed to address this, but there doesn't seem to be any clarity there. If data is shared between two agencies on the common platform (and they both make edits), who will own the data. Lastly, there are some agencies out there trying to get an HTML page with an email address secured, let alone putting all OUR data across the Internet over a VPN.

They are going to do what ever they want though, because the appearance of competent financial management outweighs competent security practices. Until there's an incident.

Ode to Useful Auditing

noreply@blogger.com (Chris) — Mon, 09 Feb 2009 15:08:00 +0000

I gave a Firetalk at ShmooCon on Saturday night. I told the people that attended that I would post the poem from the talk:

There once was a man named Steve,
Who was notified he was subject to audit.
It just about made him heave,
But he knew he could simply discredit.

The auditor sent over their test plan,
To which he responded with documentation.
And then they started to scan,
Yet he feared not for his occupation.

The scanners left to perform their magic,
Steve awaited the results package.
He had confidence that it wouldn't be tragic,
For the auditors were at a disadvantage.

One day the deliverable arrived,
Upon that was convened a meeting.
A plan that Steve had contrived,
Involved supplying the auditor a beating.

Steve began by questioning tool sets,
And continued by criticising results.
The contractor began to fret,
But didn't consider it an insult.

The "auditor" launched into his shtick,
Complete with tons of excuses.
It speckled with buzzword shit,
But his logic only confuses.

Now that management's confidence is shaken,
Steve goes in for the kill.
He announces the auditor is mistaken,
Then defines their lack of skill.

His argument lies in their false positive rate,
And their inability to ask questions.
The documentation review was a sorry state,
He finished by making some suggestions.

Remove these morons from my sight,
They are the reason auditor is a dirty word.
These reports are only meant to cause a fright,
This entire exercise has been absurd.

After which, I launched into my usual rants about why the Federal auditing needs to change.

Please note, I am not saying that auditing is dead. I am only saying the useful auditing died some years ago and it needs to be resurrected.

Missing the Point

noreply@blogger.com (Chris) — Thu, 05 Feb 2009 00:30:00 +0000

I have been keeping an eye on this story about the Justice Department testing their security awareness training. It looks like has just about played out and that most of the facts are known. So I guess I will spend a few minutes and comment.

The point of the exercise has been lost due to the media scrutiny.

It has moved onto "you caused other components so much work", "you didn't coordinate", etc, etc. My take away from this entire story is that it is a story at all.

The training program has apparently suffered an epic fail. While I admit, it was probably a bonehead move to not let the supposed target of the scam, everything else is sending a few clear messages:

The users didn't recognize the scam, they bought it hook, line and sinker. So much so, they forwarded it to their friends and colleagues in other agencies. Who then also fell for it;
Some users did realize what was happening and began to take corrective actions - specifically identified in this story;
Something that has been suspiciously been omitted are the statistics.

I did try to put together a timeline, but if there is an article about it then there is a differing timeline.

What is clear is that there is more work to be done. In the initial story I linked to, there are some words at the end about things improving and fewer people fell for it. The fact that there weren't even some vague generailities about "we sent it to 50,000 people and only 12 went to the site", tells me that it was obviously more than 12. More likely it was something embarrassing, like 25% of the targets. Also, add on people in other agencies who weren't even targetted but went to the site anyway. I think that is more than a few.

Justice will never get 100% of the people to not fall for a phising scam, I do hope that they can get it down to 12. I applaud the efforts of Justice and in the future I would like to see more of this. It looks bad from a PR perspective, I know. As a security professional, it gives me a confidence that more than a powerpoint is being emailed out as security training.

GAO: FinCEN InfoSec Program = Bad

noreply@blogger.com (Chris) — Fri, 30 Jan 2009 21:43:00 +0000

Like most bad news Washington, this GAO report was released on a Friday afternoon. This Friday afternoon happens to be before the Super Bowl of all things. So this is a special Friday where it almost certain to be overshadowed by the drama of the “Big Game”.

This report (that I got to read, believe or not) tells the story of the security posture of the Financial Crimes Enforcement Network (FinCEN). FinCEN is responsible for some important things not the least of which is keeping money laundering to a minimum, stopping terrorist financing and investigating other financial crimes. You may be interested to know that it has ties to many financial institutions, casinos and other places where big money may be. This is also the group that banks notify when you move $10,000 or more.

Ok, so now you know who they are and what they do. Here's the rub:

Although FinCEN, TCS, and IRS have taken important steps in implementing numerous controls to protect the information and systems that support FinCEN’s mission, significant weaknesses existed that impaired their ability to ensure the confidentiality, integrity, and availability of these information and systems. The organizations have implemented many security controls to protect the information and systems. For example, FinCEN employed controls to segregate areas of its network and restrict access to sensitive areas, and IRS controlled changes to a key application in its BSA processing environment. However, weaknesses existed that placed sensitive data at risk of unauthorized disclosure. The organizations did not always consistently apply or fully implement controls to prevent, limit, or detect unauthorized access to devices or systems. For example, the organizations had not consistently or fully (1) implemented user and password management controls for properly identifying and authenticating users, (2) restricted user access to data to permit only the access needed to perform job functions, (3) encrypted data, (4) protected external and internal boundaries, and (5) logged user activity on key systems. Shortcomings also existed in managing system configurations, patching systems, and planning for service continuity. As a result, increased risk exists that unauthorized individuals could read, copy, delete, add, and modify data and disrupt service on systems supporting FinCEN’s mission.

Holy F@%!, Batman!

I would say this is in the category of jobs that you don't want to have. Or at least had. One thing that I think I can infer from the report, is that the system is not classified. Meaning people didn't have clearances to work on the system. But there doesn't appear to be any discussion about that and I am not saying that it needs to be. On this point, I want to say that there is enough documentation and business processes out there to support doing this better.

Now, I am not going to keep writing and lamenting that our data isn't safe. This is a tough job and usually information security is something that gets tacked on. The ST&E portions of the Certifications on the system were probably rushed and people missed things. Some things get rushed out the door, some risks get accepted, whatever.

But seriously, there are some pretty basic things that the Continuous Monitoring efforts should have taken care of: excessive user rights, unused accounts, limited or missing encryption. Read the report for yourself it reads like How not to do Information Security. And now for the moral of the story.

The answers here and with most organizations will not lie with new technology but with leadership, a plan and processes. Some of it, like the mainframe, sounds like it needs an upgrade. The common thing though are operational keeping an eye on user accounts, monitoring the logs, IDS; those are things that need humans with eyes and analytical skills.

Predictions for 2009 (Because all the cool kids are doing it)

noreply@blogger.com (Chris) — Fri, 09 Jan 2009 18:40:00 +0000

And the answer is:

Nothing.

That's right I said it. Given the economy and the state of things, stuff like Policy Compliance and Risk Management are going to be sitting in the corner. Caveat: Unless there is a dramatic change.

That change would be something from the White House or Congress or (dare I say) Al Qaeda. If the deciders decide to take regulations and compliance seriously and start adding requirements to things like the TARP or whatever then we could see something new.

But the new FISMA does not provide for any changes to the current FIPS / 800-series documentation. It is the same ambiguous pain that we all been suffering through.

Lastly, there isn't going to be any new HOT security technology that will be coming out. It will be more of the my web app just got hacked/facebook malware/twitter worm stuff that has been emerging over the last 6 months.

We'll see. Improve your Process!

Scan, Baby, Scan!

noreply@blogger.com (Chris) — Sat, 22 Nov 2008 18:36:00 +0000

I recently experienced death by scanning (maybe death is too strong, extreme pain). The system I am supporting is eventually used by the government which means FISMA and by extension certification agents. I still do some certification agent work and I will say that it is still a foggy area. Some will take it to the Nth degree and dig in to every facet and crevice to get the best assurance possible. Others will do a superficial scan and call it a day.

My current annoyance in the ability to ascertain the security posture is this; the management of the little system wants as few vulnerabilities as possible, obviously. So naturally, their scanning policy is tailored to the system and to the excepted risks. The certification agent has their own process for assessment, good for them. However, their process does not include updating their process for the environment.

The two processes are at odds with one another, so we are constantly chasing vulnerabilities. Different tool sets, different time lines, different policy baselines, plugin updates, the list goes on. When I try to convince that less scanning needs to happen, we in fact get more.

Most people I talk to would agree, it would be good to run as many tools as possible at your environment. I am currently frustrated by it.

There really wasn't any point to this story except that scanning with 19,000 tools is helpful as long as everyone is on the same page and can adequately communicate that page. So far, I have apparently been an ineffective communicator or my communication has been accepted and then moved aside in an effort to portray a rosier picture.

A new plan will have to take shape now. Details to follow.

In which I am convinced that Cloud computing is evil

noreply@blogger.com (Chris) — Wed, 19 Nov 2008 02:33:00 +0000

I have been to the a couple of sessions at CSI over the last two days. The conference is good overall, it appears to be well organized and the speakers have been engaging. Today, I attended a session called The Fate of the Secure OS. There was discussion about many topics including arcane, outdated and poorly supported operating systems. Some discussion about maintaining configuration and keeping your users informed. But there was also a presentation on ... Cloud Computing and Virtualization.

Up until this afternoon, I didn't think that it was more than a hassle that had to be dealt with. I knew the obvious drawbacks when it came to incident handling or things like “where is my data actually stored”. I saw a presentation by Dennis Murrow of ConfigureSoft and things got really scary.

I wish I had the slide deck to make all the points, the short version of a series of questions posed to a fictional SOA/SaaS provider:

Where is my data and how are you managing it (backups, access controls, auditing, etc)?

If I choose to leave you as customer, can I get my data back and what condition will it be in?

How is the underlying hardware, hypervisor, operating systems and applications maintained and operated?

What are your policy baselines and vulnerability remediation procedures?

The list went on. To many, this is most likely old news. Judging by the way that oxygen left the room, many people seemed to be just realizing these issues. The speaker was also able to present this information in a way that didn't appear to be coming across as FUD. It just seemed like a logical progression of things to consider before ... you know ... sending your confidential, proprietary data into the ether.

After the session, many had sworn off the idea of putting their data in a cloud computing environment. There may have been a few management types that still clung to the idea that outsourced data processing and storage was a good idea.

My end takeaway is this there is no risk that anyone in their right mind can accept here, there is no assurance evidence that could make me believe that in 2008 (and probably into 2009) that cloud computing is a good idea. I could almost see that you could sell “auditor me” on virtualizing a couple servers. But the jury is still out on that one. For now, I'm with Hoff. Cloud computing needs to come along further before I can get on board, anyone considering it ... should wait until some improvements come along.

This is what I am talking about

noreply@blogger.com (Chris) — Wed, 12 Nov 2008 23:49:00 +0000

I didn't go to the presentation, but this guy's synopsis is the root of my frustration:

http://www.leune.org/blog/kees/2008/11/verizon-business-presentation.html

The idea that we can do an adequate risk assessment ... $0.
Subjecting ourselves to a fruitless process with no significant progress ... Millions
Suddenly coming to the realization that there needs to be an overhaul ... Priceless.

And the winner is ...

noreply@blogger.com (Chris) — Wed, 12 Nov 2008 02:27:00 +0000

godfadda!

Godfadda make your travel plans to sunny National Harbor, MD. Bask in the glory of the brand new Wilson bridge (and the occasional and unfortunate bouquet of Blue Plains treatment plant).

Godfadda, please contact me at cyberhiker at gmail dot com for details.

Congratulations and I will see you there!

Ticket to CSI

noreply@blogger.com (Chris) — Sat, 08 Nov 2008 19:18:00 +0000

I can't think of a good question to ask, so I am going to resort to this: if you comment that you want to go to CSI and why. Then it is yours.

CSI 2008

noreply@blogger.com (Chris) — Tue, 04 Nov 2008 14:50:00 +0000

How is that Assurance Evidence is proud to announce that will be giving away one pass to CSI 2008. This is not the free expo pass, this is a conference pass worth serious coin. I will be there on various days depending on work, life, etc.

The rules are these: The winner will need to answer a question regarding Information Assurance (probably FISMA related). The question will deal in facts, or at least my interpretation of the facts. The question will be posted Noon tomorrow (November 5th), and the first person with the correct answer will be the winner. Please leave a way for me to contact you.

Good Luck!

Schneier is on to Something

noreply@blogger.com (Chris) — Wed, 29 Oct 2008 11:10:00 +0000

I usually don't read Bruce that often, but I came across a post about Risk Management making Sense. My take away was that, we can inherently perform risk management when confronted with taking meat from a lion on the African plains in 10,000 BC. But are challenged with more complex threats and vulnerabilities.

I have been having some deep conversations with my wife and others about better ways to measure and manage risk. My recent contention is that with so many changing and evolving threats, should we just presume there will be a threat when a vulnerability is presented? Or one generic threat that could be tied to just about anything (Hacker Compromises System)? I don't know.

Getting back to the deep conversations, we try to draw parallels to cars. There are only so many things that can happen to a car, and only to varying degrees. We, as the (supposedly) responsible operator, take certain steps to reduce risks to the system (its snowing, drive slower or that tree looks like it could fall on my car, perhaps I shouldn't park there). The insurance company can infer certain things about how the car will be operated based on demographics, statistics, etc. A 16 year old football star will operate the car differently than a 42 year old soccer mom. We may also be transporting gold bars in the trunk of the car, but the car insurance people can't deal with that because they are insuring a 1986 Toyota Tercel not 37 million dollars in gold bars.

In this story, we only ever really care about impact (my car's been stoled with gold in the trunk). But we wouldn't be driving an '86 Tercel with all that gold in the trunk. My stuff would be in an armored convoy with air support (ala Italian Job). One could argue that putting your gold in a Toyota is a bad move (it is!). However, inside organizations all over the world, it is happening right now. Because of the intangibles that aren't or can't be (easily) measured.

Gold is something we can assign a value to, at the time of writing $749.11 an ounce. Data that could be turned into Information and then Knowledge, generally has only intrinsic value to the information owner (IO). They just need a place for it to live and be processed. The System Owner (SO) can't assign an discrete value to the information, because the SO doesn't know the costs associated with creating it. Further, SO doesn't know possible damage in case of leakage, corruption or inaccessibility. The SO has more to worry about in the face of inexperienced staff (the 16 yo jock), problems with the data center (tree falls) or any other metaphor you want to assemble.

My end point here is: how do we measure risk in a way that says what needs to be said and warrants the controls needed (and justify buying a newer, more secure car; like the Mercedes with the laser cut keys).

Go Vote!

noreply@blogger.com (Chris) — Mon, 20 Oct 2008 15:00:00 +0000

I would like to add my two cents here for the few people that read this blog.

Go Vote.

I am not going to tell you who to vote for but I will say that it is important to vote. I watched Recount and Hacking Democracy recently and to say that I am upset would be an understatement.

So go vote, do not be discouraged or turned away. Our forefathers have fought and died for the right for us to vote.

Be counted.

Loss Prevention is not Risk Management

noreply@blogger.com (Chris) — Tue, 14 Oct 2008 18:34:00 +0000

I have been giving a lot of thought about how to deal with Risk Management recently. I have talked to a few people and I have come to realize the title of this post. Many of my colleagues only talk about making sure the data doesn't get released, corrupted or unreachable. In my own little head, this to me is loss prevention. Retailers do it all the time, they put those annoying tags on the clothes so that you can try them on properly, to make sure that they don't experience a loss. I'm not saying that the RM and LP are not related, they are. But a loss prevention is the
implementation of controls is not a risk management. I am define risk management as (like Wikipedia):

a structured approach to managing uncertainty related to a threat, a sequence of human activities including: risk assessment, strategies development to manage it, and mitigation of risk using managerial resources.

Most of the time, I have started the risk assessment process with a threat identification, where we list out all the threats. The question is "Do we care?" The answer of course is "No". Stick with me now. Has the person in charge ever turned to you in the beginning of the incident
response ever turned to you and said "I have the Risk Assessment here can you tell me which threat succeeded and which control failed?" Maybe a few but not many, the question that they asked me was, "What failed and (delicately) how do we get the shit back in the horse?" Results not causes. In the heat of the moment, I haven't met anyone that said "I spent three days with a
CVSS calculator determining that the threat is a 2, xxxxxxx turned into a ... ."

You know the next steps, list of threats paired to vulnerabilities, and if you are using the 800-30 then you do the arbitrary but necessary likelihood and impact. To come up with a risk. And there was much rejoicing. Yea! I have checked the proverbial box, submitted my POA&M and now I will retire to the veranda for coffee without a care in the world, right? Wrong.

My perception is that we are working this thing backwards, at least in the Federal government space (which is all I am really familiar with). With the Feds, we know the controls we are going to implement (800-53 or CNSS 1253). And then we know what we don't want to happen, you know ... bad stuff that gets us in the Washington Post or dragged up the Hill.

So let me lay this out, the threats are changing, there are always new vulnerabilities (the only constant is change ), the likelihoods and impacts are subjective so why should we expect anything from that process. Or at best, something we can take action upon.

I have watched many smart people stand up new firewalls, IDPS, NAC solutions, SOCs, AV, whatever and still in the end something gets missed or the human element gets in the way. Because simply implementing and monitoring controls without the understanding of the risks those controls are protecting against is not good. It is just doing Loss Prevention.

Put down the DCID 6/3 and walk slowly towards me

noreply@blogger.com (Chris) — Wed, 01 Oct 2008 19:32:00 +0000

While this does not personally excite me since I don't live in an IC or DoD world, the ODNI has abandoned DCID 6/3 in favor of the new CNSS instructions. It is only about a year late, since the first time I heard this was happening was in 2006 with an implementation of 2007. The news release is here: http://www.dni.gov/press_releases/20080930_release.pdf

The directive is here: http://www.dni.gov/electronic_reading_room/ICD_503.pdf

And I found out about it from here: http://infosecurity.us/?p=1918

Thanks Mark!