This is the first of two postings that will begin to address some ways to test something that hopefully you will only encounter rarely in your auditing career, but it something that I have seen in a number of organizations that are in the earlier stages of the IT maturity model- audit preparation versus good practices in place. In some cases, you may be tipped off to this by howpersonnelare behaving before your technical test-work ever gets started... Too often I hear, "we're ready for the audit- we've spentthelast month getting everything ready." In some of these cases, it can cause one to wonder whether or not they "get it". If you have prudent practices and processes in place, then there's little to "prepare" for.
In this blog entry, I'll focus on just two of the many possible scenarios where technical testwork may indicate signs of audit prep rather than good processes in place. You'll have to look at all of your testwork collectively in order to try and determine whether or not that is indeed the case, or what exactly was the root cause of a particular issue(s).
So let's set this up... Let's say you work with the internal audit department for a large organization, and you are charged with performing an IT review of one of the unit members. They have never had a technical review, and you hear that they have been preparing for the audit for the last few weeks.
As the review starts, you notice that the help desk is handling a lot of support tickets regarding personnel having difficulty when setting or changing their passwords... This could be a tip-off that a new password policy (which you have already reviewed) along with its corresponding technical control has only recently been put in place prior to the onset of the audit/review. At this point, asking a few employees a few questions to help confirm this notion may be prudent. And always keep in mind that in many cases, you are concerned with the entire audit/review period, not just the day you went in to gather your information andperform your testwork.
As an auditor, part of what you are charged with is to validate (confirm) that the administrative controls that are in place (e.g. policies) are effective and that wherever possible, technical controls are in place that correspond to and enforce thosepolices, business objectives, and/or regulatory obligation(s). To achieve these two objectives, first you may need to review the policies and procedures that the organization has in place. You should compare them against applicable laws, regulations, and other prudent business/leading practices. In some cases, putting together a policy and procedure gap analysis (sometimes referred to as a policy and procedure crosswalk or diagnostic) may be an effective way to accomplish the first objective.
As the review progresses, you may interview personnel to get a better understanding of their operations, what kind of systems and/or data the business depends on, and you will inevitably request a listing of servers and information resources. This listing of systems may include attributes such as:
- a description of the system;
- the installed applications and their version;
- what operating system is installed;
- whether or not the system is mission critical;
- whether or not it contains or touches a protected type;
For example, if an organization has a policy in place that states that employees change their passwords every 90 days, you need to be able to validate that (1) the technical enforcementmechanismsare in place, and (2) if possible, that they have been in place for the review/audit period (as some things may lend themselves to being able to discern this more than others...). Let's assume, for this example, that theorganization is a Windows shop.One quick way to determine what the password controls that are enforced is to run the secedit command on one of the domain controllers. For example:
secedit /export /cfg seceditOutput.txt
This command has the secedit utility export the configuration to a text file named "seceditOutput.txt" (which will be output into the directory the command is run from, as well create a log file on the server it is run from). Three relevant lines from the output are shown below:
MaximumPasswordAge = 90
MinimumPasswordLength = 8
PasswordComplexity = 0
Note the effective password policy is basically, 90 days maximum password age, with a minimum length of at least eight (8) characters, and complexity is not enforced...
Keep in mind that for some organizations may have multiple password criterion, and/or fine-grained password controls in place, and/or use third-party tools to enforce password polices, and you may need to do further due diligence. However, as in the previous blog post (seeIT Auditing with Minimal Intrusiveness), the information provided by the [scripted] output may not necessarily present the whole picture in and of itself, but it's a starting point- although in many cases the output from secedit will in fact be exactly what is in place, and the only password policy in place...
If the organization's policies state that passwords should be changed every 90 days, and that the minimum password length is 8 characters, and that complexity should be enforced, then it looks like all criterion with the exception of complexity is in place... So already, one observation should be noted. However, lets should not stop there- yourprofessionalskepticism should kick in dictate that yougo a step further and determine when exactly users did last change their passwords. Of course, this can be accomplished in a variety of ways... Since I am a big advocate of scripting commands to generate useful output in order to validate controls, I will focus on getting the information via the command line and PowerShell (although VBS scripts could be used as well). In this case, you could use either a standard command prompt and built-in command line tools on the Active Directory Controller, or use the Active Directory modules for PowerShell (standard on 2008r2 Domain Controllers, but can be added on 2003r2 and 2008 ADC's) to generate the output you could use for your analysis.
For this example though, we'll focus on the output from thecsvde command, as it can provide a wealth of information, as has the ability to export a comma separated listing of the domain objects in the Active Directory that can be sifted, filtered, and explored... For this example, we'll just focus on three data elements from the output to determine when users actually changed their password last:
- userAccountControl - filter to show values like 512 (account enabled) and 66048 (account enabled, password doesn't expire)
- sAMAccountName - the login/userID
- pwdLastSet - date the password was last set
|userAccountControl||pwdLastSet||Password Last Set (derived via formula)||sAMAccountName|
|512||129473442650201000||Friday, April 15, 2011||jdoe|
|512||129473442650245000||Friday, April 15, 2011||dbrown|
|512||129468332650201000||Friday, April 9, 2011||astone|
|66048||127573582597498000||Thursday, April 07, 2005||msmith|
|66048||127075148908458000||Monday, September 08, 2003||fancyexec|
|512||129451837342799000||Monday, March 21, 2011||joeworker|
|66048||129260123886088000||Wednesday, August 11, 2010||newguy|
|66048||128793619729609000||Tuesday, February 17, 2009||administrator|
Let's say the information was extracted on April 15, 2011, and that the above eight entries is indicative of the entire data set... Based upon the derived "password last set" dates in the table above, do you see anything that looks out of sync with the organization's policy that states that passwords should be changed every 90 days, and the technical controls that you observed (MaxPasswordAge = 90)? I suspect that you do. At this point, these are technically not yet observations, but are talking points with your point of contact as to why thediscrepancyexists... Based upon the help desk issues that were noted when you began (the high number of password reset issues), and some of the dates that popped up, it may appear that the technical controls were only recently put in place for the audit as opposed to being in place for at least the review period (note that the csvde output will have otherattributesto help you lean more towards one way of thinking versus another- but that's another blog post). You may also want to inquire as to why certain users are allowed to circumvent policy by having non-expiring passwords (those with the userAccountControl value of 66048)- keeping in mind that they may have a documented, valid business case, but they should have other compensating controls in place for these accounts as well...
Now, the above example may be considered a bit simplistic or contrived, but it's for illustrative purposes, and you probably get the general idea... One would expect though, that for a domain controller that's been in place for a while to have "password last set dates" drifting apart from one another at each passwordexpiration (since users are generally given a week or so warning before their password expires)even if they were all originally set at the same time. That being said, I have walked into places where a new ADC was just deployed, and everyonejustreset their passwords the week prior (not a lot of history to go on there). But I digress... :)
For the next test, you want to vet the patch management process for several things- (1) to see if it's occurring at all, (2) if it occurs on a timely basis (note that this may be based upon their own definition of "timeliness" in their policy), and (3) if it's consistent. During your policy review, you noted that their policy states that "Windows patches will be applied within 90 days of release, and that Windows security patches will be applied within 30 days of release." One would expect some consistency with respect to when patches are applied, as even if the custodians of the Windows systems waited 90 days to apply a particular patch(es), they would still be applying patches almost every month (yes, you need to do some duediligenceto determine when patches are released and when there are month(s) when patches are not released). A simple command to extract this information from a Wind0ws operating system is:
wmic /output:"patchlist.csv" qfe list /format:csv
The command will produce output that can easily be pulled into Excel, and sorted by the "InstalledOn" attribute. This can help you determine if patches are being installed in a consistent and timely manner. If you see a huge number of patches all installed just as the audit/review was kicking off, this may indicate audit prep rather than good processes in place. Keep in mind though there could be many reasons for what you see, and that things have to be put in context. Once you've seen a couple hundred of these, you start to get a feel for things... :) You also come to know theidiosyncrasiesof various Windows operating systems and how they report the "InstalledOn" date (as two in particular provide dates in 64-bit hex format using the wmic command, but not when using PowerShell...).
Anyway, these are just two simple ways to start recognizing the possible issue of "audit prep versus good processes in place" at a client. If indeed that ends up being the case after you've done your due diligence, then meaningful recommendations would need to be made to address this...
That's it for now. Next time I'll cover a little bit more "audit prep versus good processes in place" for UNIX/Linux in the next post, and then I'll start on handy commands and scripting...