Friday, July 29, 2011

July 2011 STIG updates, part 2

Checking the DISA site today, I see more STIGs have been updated:

Network Infrastructure Router L3 Switch - Version 8, Release 7 - Updated July 28, 2011
Network L2 Switch STIG Version 8 Release 7 - Updated July 28, 2011
Network IDS/IPS - Version 8, Release 7 - Updated July 28, 2011
Network Firewall - Version 8, Release 7 - Updated July 28, 2011
Network Other Devices - Version 8, Release 7 - Updated July 28, 2011
Network Perimeter Router L3 Switch - Version 8, Release 7 - Updated July 28, 2011
Network Policy - Version 8, Release 7 - Updated July 28, 2011
BlackBerry STIG - Version 1, Release 6 - Updated July 28, 2011
Radiant Mercury (RM) 4.5x STIG Version 1 Release 3 (*PKI) - Updated July 28, 2011
DSG Version 2 Release 1 Procedures - Version 1, Release 3 (*PKI) - Updated July 28, 2011
JVAP Administrative STIG Version 3, Release 12 (*PKI) - Updated July 28, 2011
DoD Host Based Security System (HBSS) STIG - Version 3, Release 3 (*PKI) - Updated July 28, 2011
Internet Explorer 6 STIG - Version 4, Release 4 - Updated July 28, 2011
Internet Explorer 7 STIG - Version 4, Release 5 - Updated July 28, 2011
Mozilla Firefox STIG - Version 4, Release 3 - Updated July 28, 2011

As with yesterday's post, STIGs marked with an "*" are in the CAC-protected section of DISA.  Also note, there is a date of "July 28, 2011" associated with these updated STIGS.

Thursday, July 28, 2011

July 2011 STIG updates

By my calendar, STIGs were supposed to be released tomorrow.  It appears many have been released today.
Draft Microsoft SharePoint 2010 STIG Version 1, Release 0 - New July 28, 2011
Windows 2008 STIG - Version 6, Release 1.15 - Updated July 28, 2011
Windows 2008 STIG - Version 6, Release 1.15 (*PKI) - Updated July 28, 2011
Windows 2003 STIG - Version 6, Release 1.22 - Updated July 28, 2011
Windows 2003 STIG - Version 6, Release 1.22 (*PKI) - Updated July 28, 2011
Windows XP STIG, Version 6, Release 1.22 - Updated July 28, 2011
Windows XP STIG, Version 6 Release 1.22 (*PKI) - Updated July 28, 2011
Windows Vista STIG, Version 6, Release 1.22 - Updated July 28, 2011
Windows Vista STIG, Version 6 Release 1.22 (*PKI) - Updated July 28, 2011
Gold Disk - Updated July 28, 2011
Mac OS X 10.5 STIG, Version 1, Release 2 - Updated July 28, 2011
Mac OS X 10.5 STIG, Version 1, Release 2 (*PKI) - Updated July 28, 2011
z/OS ACF2 STIG - Version 6, Release 8 - Updated July 28, 2011
z/OS ACF2 STIG - Version 6, Release 8 (*PKI) - Updated July 28, 2011
z/OS RACF STIG - Version 6, Release 8 - Updated July 28, 2011
z/OS RACF STIG - Version 6, Release 8 (*PKI) - Updated July 28, 2011
z/OS TSS STIG - Version 6, Release 8 - Updated July 28, 2011
z/OS TSS STIG - Version 6, Release 8 (*PKI) - Updated July 28, 2011
zOS SRR Scripts Version 6, Release 8 (*PKI) - Updated July 28, 2011

Note that the draft of the SharePoint 2010 STIG has been released.  Also note that the Gold Disk and the STIGS noted with with an "*" are located in the PKI protected area of DISA.

Tuesday, July 19, 2011

DISA may have been hacked

Here's the link.

Keep your eyes on the news for more to the story.

Monday, July 18, 2011

What are STIGs and where are they found?

In looking at traffic sources for the blog, I've seen that people have reached this blog by searching for "what are STIGs?" or "where are STIGs found?" So, in a small effort to answer those questions, I thought I would answer as best as I could.

STIG stands for Security Technical Implementation Guide, and is the "configuration standards for DOD IA and IA-enabled devices/systems." (From DISA) STIGs contain the guidance necessary to harden or secure a specific device, piece of hardware, platform, operating system, server, cross-domain solution, and potentially an application. A joke in the industry is that if something can be plugged in (to the network,) there is a STIG for it. That saying is almost true. A "checklist" is usually coupled with a STIG, and gives instructions to manually check and configure compliance to a particular STIG. An example is that there is a Windows XP STIG which gives the guidance on how a Windows XP machine is to be configured in order to meet the DoD's security posture. The Windows XP checklist tells you specifically how to check to see if that machine is in compliance, and if not; how to fix it.

Gold Disk is the de facto host-based tool used to check operating system compliance with regards to Windows operating systems. Currently (as of this writing) there is no support for Windows Server 2008 R2 and Windows 7. Running Gold Disk will show you how your operating system fares against the particular checklist. According to the FAQ on DISA's site, Gold Disk is being phased out in favor of SCAP-compliant tools.

There are Security Readiness Review (SRR) Scripts that help automate checking controls for a few of the checklists. A couple of the SRR Scripts I have used with some regularity are the MS SQL scripts, Oracle SQL Scripts and Unix scripts.

A note on Gold Disk and some SRR scripts: Many of the actual scripts (and some of the STIGs that contain FOUO content) are housed in a CAC-enabled site in order to control their usage.  You will need a CAC in order to retrieve those documents/scripts.

So, where are STIGs found? The STIGs are found on the STIG home page, which is part of the Information Assurance Support Environment (IASE).  The sponsor for IASE is the Defense Information System Agency (DISA.)

STIGs and tools are updated on a regular basis to address to platforms, new vulnerabilities, and new patches for those platforms.  Older technologies are retired, and periodically, new STIGs are released in order to address new technologies.

Wednesday, July 6, 2011

Does what we do matter? Explanations from Lenny and Alan

Yesterday, I read a great post by Lenny Zeltser on four reasons why security assessment reports get ignored or unread.  The reasons he put forth are spot on; and, as a DoD auditor, I see this first hand.  I think many times I see this, the reasoning is actually a combination or a blend of some of his reasons.

If you have not read his post, allow me to direct you there....the post is not long.

I'm not one to rant (much) but some of these reasons really fly in the face of the DoD.  The Department of Defense has specific guidelines and regulations that must be followed in securing the IT infrastructure.  These guidelines are called out in various instructions, like DoD 8500.2.  I do not have a problem going on site and finding controls that are not compliant; there may be a justifiable reason, or plain ignorance may leave a control or two in a non-compliant state.  The issue I have with some units/networks/enclaves/bases is when we go to audit a site multiple times and we find the same non-compliant controls.  Sometimes we find more non-compliant controls than a previous audit.  Then, I know that there is an issue.

Point three (from Lenny's post) is how I attributed the non-compliances we found; I used to assume that an over-worked, under-staffed IT/IA department had too many fires to put out.  The commanding officer can not get his email.  Or reach Facebook.  Or, a router has gone down.  Or, the SQL database is down, and the main application used by unit is unusable.  I get it.

However, there are units that we have audited more than three times (as the accreditation cycle revolves) and the units have the same number of non-compliances, or, in one base's situation, more.  One base that we have audited multiple times actually got worse between audits.  On these trips, I saw ambivalence by the administrators.  It was almost that they did not care that we were there doing our job, as they were almost non-responsive to us when we asked for help.  We may have seen ignorance, but how can you not know that you have a SAN in the data center, or that half the servers are virtualized and therefore subject to the ESX checklist.  Over the four years, they received from us at least three DIACAP reports, including POAMS, that they could use to track open issues.

It was only when the Inspector General's office started sniffing around and threatened to pull the plug because there was no activity to remediate open findings that the unit sprang into action.

Alan Paller had a great editorial opinion in the December 17 2010 issues of the SANS NewsBytes.  Because I don't have a link for the quote, I'll reproduce it below:
EDITORIAL: "Accredit and Forget It": How Some U.S. Government Agencies
  Fib On Cyber Security (Alan Paller)
First a few words about how the system works: Before a federal system is allowed to go online, it must be given "Approval To Operate" (ATO) status.  Only a Designated Accrediting Authority (DAA) is allowed to accredit a system and give it an ATO.  Any security weaknesses exposed to the DAA generally needs to have a fix defined and scheduled for implementation and listed in an Information Technology (IT) Security Plan of Action and Milestones (POA&M).  If there is no plan to fix the weaknesses, the system is not supposed to be granted ATO status.  That's how the system works, but with one damaging addition.  A lot of the most important fixes are not made - ever.  They stay on the POA&M for so many months or years, without action, that the whole process has been given the nickname "accredit and forget it." Sometimes the agencies notice how long they have ignored an important action. When they do, they take it off the POA&M and put it back on, with a new start date. That way it doesn't look like it was ignored, even though it was.  Then last week we learned from a contractor that one of the large civilian agencies has automated the process of changing the date.  If an action has stayed on a POA&M for too long, the computers automatically change its start date so it appears to have been just added. That way it doesn't look like the agency is skimping on security.  If senior executives in the White House want to wake up a the CIOs and show them security matters, they could make that "automated fibbing system" a very public career-ending mistake for the CIO of that agency.

I truly believe that this occurs more often than not, and the data from auditing trips bears it out.  I would love for there to be some sort of check an balance for when you know the client (system/unit/enclave/base) is just paying you lip service in order check off a box (see point 1 in Lenny's post.)  I have seen a few of my (now ex-) coworkers leave this sector because the constant flouting of the open controls or mis-management drove my co-workers to the realization that our work does not matter.  And sad to say, I can not disagree with those (now) ex-coworkers.

We are supposed to move to NIST-controls.  We are supposed to start embracing SCAP tools.  I do not know if that will help, but I am hoping that some kind of change will bring about more remediation.

As I said before, I do not like to rant; I would rather work on a solution to the problem.  But, it is getting more and more frustrating as the problem becomes more pervasive.

Tuesday, July 5, 2011

June 2011 STIG updates

I mentionied that I was out on vacation last week.  DISA released a couple of STIGs:

Windows 2008 R2
Network Perimeter Router L3 Switch
Blackberry STIG
Windows 2008 DC STIG Benchmark
Windows 2008 MS STIG Benchmark
Windows 2003 DC STIG Benchmark
Windows 2003 MS STIG Benchmark
Windows Vista STIG Benchmark
Windows XP STIG Benchmark

Windows 2008 R2 is still not supported by the Gold Disk.

Monday, July 4, 2011

Back from vacation

So, as I mentioned in the previous post, I'm back from vacation.  I read a good book, and took some time to flesh out where I seem to be headed.  Vacation gave me a chance to look at the big picture and work out some of the issues I see in various career paths.  I really don't know where the government job is headed; I know where it is supposed to be headed.  But I fear what the company is doing is not enough, and I think we are losing out on contracts we should be winning  A year from now, will the company still be here? I suspect "yes" but I'm not sure our division will.  At least, if it is, I'm not sure that it will look anything like it does now.

So, I've been putting in extra hours with my own company.  I've joined a different Chamber of Commerce, one that is more local; and I hope to derive more business from the people I know.  I prefer to run my own business, as it gives me more pleasure.  Sure, there are more pressures, but I'm pushing to build the client base such that I can be more reliant on my own business.

Tomorrow, it will be back to the grind.  At least I have a clearer head. And we'll see where this all goes.

A mini-review of Ninja Hacking by Wilhelm and Andress

I have just come off a vacation where I tried to disconnect from being overly technical.  Typically, on my breaks I read technical books to enhance something I know or I read something in-depth to learn a new skill.  This past week, I wanted something relevant, but not overly technical.  I saw an ad for "Ninja Hacking:  Unconventional Penetration Testing Tactics and Techniques" by Thomas Wilhelm and Jason Andreas, and decided this fit the bill perfectly.

To start off, let me say that the book is aptly named.  The use of the word "ninja" is not just used as the adjective to describe a good coder or pen tester; all of the concepts in the book relate to the ancient ninja of feudal Japan.  The point of the book is to introduce concepts of penetration testing with the arts and practices of the ninja.

So, here is what I liked:  First, the book devotes the first two chapters to the history of the ninja in Japan.  I can honestly say that prior to reading those two chapters, my concept of ninjas was what Hollywood depicts in movies.  The first two chapters shed light on what the ninjas were really like, how they operated, why they were necessary, and what tools the ninjas had at their disposal.  Succeeding chapters took those tools and applied them to how penetration testers should think differently to accomplish their goal.  I really liked the discussion on strategies and tactics.  Some of the examples given to disrupt a system administrator were:  call them at 2 A.M. with a trouble ticket, send them an email from HR with an issue about their insurance, or leave a note on their car that they have parked in the wrong space.  Good stuff.  All of those are activities that will have someone thinking differently when they should be paying attention.

Also, the chapters might have discussed various tools and methodologies, but not at a low level.  For example, the chapter on discovering weak points in area defenses had a discussion on sniffing network traffic.  In the discussion Kissmet and Wireshark were both discussed, but only to introduce the tools to the reader (if they did not know of them) and provide the reader with the resources to learn more about them.  Each chapter had a page of end notes that included links to tools, articles, and other references for further study.

A couple of issues I found:  the title of the book includes "unconventional penetration testing tactics..." and to me, penetration testing refers to systems, networks and applications.  I understand that a target may be a building or a person.  Many of the chapters discussed the latter, buildings and people and did not necessarily apply to computers.  There was a section of the book that discussed torture; and while interesting, is not something I'll be employing.  There was a section in the chapter on discovering weak points called "Gates, Guns, and Guards."  While these are valid security concerns, I don't think they come up in your average day-to-day penetration test.  However, the authors extrapolated the scenarios to the logical (cyber?) world and created successful analogies in how to employ the tactics to the computer or network. 

Overall, I enjoyed the book.  It opened me up to thinking of different ways to conduct penetration tests and employ some tactics I would not have thought of.  I really enjoyed that the book was not overly technical such that I read through and jot down areas for further exploration.  And, I liked the chapters on the history of the ninja as I could dispel some of the Hollywood myths and legends for what the ninja truly were.