A weird title, I know. Here is the situation that transpired. I was auditing a system at a client site where we were given admin-level credentials. I was able to log in to the server through RDP, but try as I might, I could not map a drive to the share that was created for us on one of the local file servers. It mapped fine on the testing laptop. The system admins assured me that my credentials were good and that all servers had the same permissions on the subnet. And, all servers were on the same domain. My co-worker gave me this tip:
First, map the drive on the local test laptop.
Next, start an RDP session to the server you are auditing.
Enter the address of the server. But, before clicking connect, click the options button.
On the Local Resources tab, click the drive that you mapped to the share.
Then, you can click connect.
When you connect, the server you are auditing will be able to see the share through your laptop. It is sort of like a proxy.
The trick is pretty cool, and worked like a champ for the rest of our testing.
Monday, August 29, 2011
Tuesday, August 16, 2011
August 2011 STIG releases
I happened to be checking DISA for something unrelated, and I saw the following STIG releases:
I think this is the last of the releases until the next quarter.
Windows IAVM Benchmarks (HBSS only) - Updated August 15, 2011
Windows 7 STIG Benchmark Version 1, Release 5 - Updated August 15, 2011
Windows 7 STIG - Version 1, Release 5 - Updated August 15, 2011
Windows 7 STIG - Version 1, Release 5 (*PKI) - Updated August 15, 2011
Draft Solaris 9 SPARC STIG - Version 1, Release 0 - Updated August 3, 2011
Draft Solaris 9 x86 STIG - Version 1, Release 0 - Updated August 3, 2011
Draft Solaris 10 SPARC STIG - Version 1, Release 0 - Updated August 3, 2011
Draft Solaris 10 x86 STIG - Version 1, Release 0 - Updated August 3, 2011
Microsoft Office 2007 STIG - Version 4, Release 5 - Updated August 2, 2011
Windows 2008 DC STIG Benchmark Version 6, Release 1.15 - Updated August 2, 2011
Windows 2008 MS STIG Benchmark Version 6, Release 1.15 - Updated August 2, 2011
Windows 2003 DC STIG Benchmark Version 6, Release 1.22 - Updated August 2, 2011
Windows 2003 MS STIG Benchmark Version 6, Release 1.22 - Updated August 2, 2011
Windows Vista STIG Benchmark Version 6, Release 1.22 - Updated August 2, 2011
Windows XP STIG Benchmark Version 6, Release 1.22 - Updated August 2, 2011
I think this is the last of the releases until the next quarter.
Thursday, August 4, 2011
Fixing CAC access to a website when certificates seem to be the problem
A co-worker lost CAC access to ONE of the DoD websites we routinely access. One, of the four or five we use on a regular basis. We tried switching browsers. We tried removing certificates. We tried re-installing (from our install file.)
In the end, it seems like following the instructions in this PDF did the trick.
Ultimately, I think the install-root file for the root certificate was newer than our file, and so I believe newer certificates were added. Also, the PDF mentioned some specific certificates that had to be removed.
In the end, it seems like following the instructions in this PDF did the trick.
Ultimately, I think the install-root file for the root certificate was newer than our file, and so I believe newer certificates were added. Also, the PDF mentioned some specific certificates that had to be removed.
Monday, August 1, 2011
July 2011 STIG updates, part 3
This looks to be the last of the updated STIGs:
I will update if there are any more updates.
RAS Remote Access Server STIG Version 2, Release 5 - Updated July 29, 2011
Remote Access Policy STIG Version 2, Release 5 - Updated July 29, 2011
Remote Access VPN STIG Version 2, Release 5 - Updated July 29, 2011
Remote Endpoint STIG Version 2, Release 5 - Updated July 29, 2011
Remote XenApp ICA Thin Client STIG Version 2, Release 5 - Updated July 29, 2011
I will update if there are any more updates.
Friday, July 29, 2011
July 2011 STIG updates, part 2
Checking the DISA site today, I see more STIGs have been updated:
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.
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.
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.
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
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.
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:
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.
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.
Subscribe to:
Posts (Atom)