I was recently having a conversation with a friend who was lamenting that Loggly and LogEntries weren’t authorized and that their Management team had put the kibosh on self-hosting Splunk (let alone a Splunk cloud install). What’s a security dude to do?

The answer lies in open-source. More specifically, Graylog. And I don’t mean enterprise, I mean loading up Graylog, probably as a Docker container, and start implementing some of the marketplace plug-ins. I would also recommend tying Graylog to LDAP so that there aren’t additional accounts to manage. It was a no brainer to me, but you never know about other people’s politics.

Now that Graylog is running and accepting log data, you can update your baseline configuration so that only the service account for the forwarding service on your workloads can access the audit logs. System admins and DevOps should only have read access to the logs. Security Admins should only have read access to the logs. And Graylog should have a big ass alert whenever root or the service account clear the logs. Was a ticket submitted for that?

No matter, whenever someone needs to see the logs — the answer is “Check in Graylog.” Because you tied it to LDAP or AD, it is as simple as logging in and putting to use the training that was given to them on how to use Graylog (*snickering* There’s never time for training! *snickering*)

I’m not being paid for this but I am getting frustrated with the “we can’t because of cost”. The product cost will not be the end issue either. The real cost is that someone now must watch it. You now need to put bodies in front of screens to create reports and alerts. Otherwise you are not compliant.

So quit your bitchin’ and start logging your shit.

AU-6, AU-7 and AU-9 On the Cheap was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is still a Thing was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

So that’s it.

Moving was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yesterday, I said that the recent survey about FISMA failure is horse shit. I stand by that claim and will now add more.

The only thing this report says is that their process is too focused on compliance and they wish they had more money. When is the last time that you talked to someone where they didn’t wish they had more money for their program? Whatever the program was. “I wish I had more money for building my space station” or “If I had another $2 million dollars, I could get something with red blinking lights instead of blue blinking lights.”

This survey has had it’s effect, we’re talking about FISMA. The failure does not lie in the law though. I see and hear about the failures every day. Management buy-in is lacking, risks ignored, security bolt-ones at the end of the project, or security isn’t keeping up with technology. I think that just about everyone in this industry could say all the same things. And they don’t have a law to tell them they have to do it. A lot of organizations have no prevailing regulatory requirement to follow and those security folks have to get more done with much less than the government provides to a lot of agencies.

One of the slides said that nation-states were attacking the government systems all the time. Whatever, everyone is getting attacked by nation-states.

A different slide said that users were their problem and they didn’t have enough training budget. To this, I refer you back two paragraphs where virtually every CISO/ISSO complains about this.

I said on the Southern Fried Security podcast FISMA episode that FISMA improved Federal government security. Anyone that can prove other wise please step forward. Because when FISMA was passed many agencies were lucky to have a firewall and anti-virus. Let alone web application firewalls, intrusion detection systems and pen tests. No one was training users on security awareness on a regular basis (not for the places I was working for anyway).

In the end, FISMA leaves the implementation of policy to the agencies. That policy should be based on 800–53. If you need help, I am here for you.

That is all.

Posted with Blogsy

More Annoyance was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

The essence of it being that FISMA is a failure (still) and government doesn’t know how to secure a rowboat let alone the vast number of systems in existence. Also that

No information security program is perfect, and based on this article many think that they are going to improve their programs simply because of continuous monitoring. Wrong.

The continuous monitoring needs to effective. Not lip service. Many agencies are hindered by congressional budget wrangling in the form of sequestration and other stupidity. They are further hindered by grand standing and empire building. The thing that seems to be lost is that they probably could do better if someone wasn’t telling them they only need

The title of the article states that they can do better. But most of the time, it’s the basics that are failing agencies.

What you need:

• Get a decent policy document together based on 800–53 Rev 4 (this includes tailoring and filling out all the little spots you are supposed to);
• Assess your risks and not just your policy violations or exceptions;
• Centralize what you can (if you’re a big agency or department, why not use the economics of scale? i.e. IR, Media Management, Asset Management, other less sexy things);
• Plan, Plan, Plan;
• Train, Train, Train;
• Scan, Scan, Scan;
• Patch, Patch, Patch;
• Watch your logs; and finally
• Accept your failures and learn from them.

The article alluded to some of this. But if you have a decent program then your compliance will happen.

That is all.

Annoyed was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

See you there!

Not Quite Dead Yet was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Review of 800–30, Rev 1;
• RedSpartan

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

Just So You Know I’m Not Dead was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Wim Remes for ISC(2) Board of Directors was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Feds and Amazon Web Services was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

My Take on 800–128 (Intentional Rhyming Attempt) was originally published in How is that Assurance Evidence? on Medium, where people are continuing the conversation by highlighting and responding to this story.