More Baselining Ideas – The Baselining Process

So I’ve had some questions about exactly what I mean by baselining and what types of things an auditor should be baselining when they’re examining a system. So let me take a few words to clarify what I meant.

First of all remember, the reason we perform a baseline is to determine if changes to the system change the security level of the system being examined. Ideally we are establishing a baseline of a system in a “known good” or secure state. In government terms this might be likened to a certification and accreditation process. But the idea is to identify a snapshot of what “secure” looks like for a given system. Then by performing subsequent baselines of the system and comparing them to the original, we will be able to see if there are any unauthorized changes to the system and if those unauthorized changes lower the overall security level of the system. This process works for auditors, incident handlers, forensicators, and others looking to assess the security level of a system.

So the baselining process would be:

  1. Build a clean system / declare a system to be secure.
  2. Create a baseline of the system in the “known good” state.
  3. Engage in a healthy change / configuration management process.
  4. Update system baselines after every approved change.
  5. Periodically create a new baseline of the system’s current state.
  6. Compare the most recent baseline to the last “known good” baseline.
  7. Analyze the two baselines for differences.
  8. Repeat / remediate risk if necessary.

We can use this process to look for unauthorized changes. Unauthorized changes to a system very likely can be indicators of a bigger problem, and most definitely something an auditor would want to be aware of when performing an assessment.

Next we’ll cover what to baseline and how…

Baselining as a Primary Audit Tool

So if I was trapped on a desert island and only had one audit tool that I could have with me to audit the island’s DHARMA systems, which would I want…

For me the answer would have to be baselines. As an auditor, ideally I want to ensure that an organization’s technology systems reflect a conscious decision on the part of the organization. In other words, I want to ensure that technology has been implemented, with a full understanding of the potential risks those systems pose, and that they have been implemented in a systematic, tested, and documented fashion. Or said another way, I don’t want to see an organization deploy systems in an ad hoc manner that exposes them to risk – I want to see controlled implementations.

A huge indicator of a controlled environment is documentation on the system being implemented. Specifically I’m looking for documented system baselines which demonstrates evidence of conscious decisions on the part of the organization to protect and secure their information.

RSA, a security division of EMC, in their Information Security Glossary defines baseline or baselining as the following:

“An effective method for identifying security attacks on a network, baselining starts by measuring normal activity on a network or network device. That measurement is used as threshold, or baseline, to detect unusual patterns or changes in levels of activity. With this method, the security expert can focus efforts on evaluating anomalies instead of looking for them by reviewing huge log files. The term is also used to refer to other security practices. A baseline, or security baseline often refers to an organizational standard for securely configuring network devices. It can also refer to the results of an organization’s first security assessment. This becomes the baseline against which the organization measures improvements and changes.”

For most auditors understanding the concept of a baseline is the easy part. The devil, it turns out, is in the details. The information auditors really want to know is what information should be baselined and then practically how do you go about performing that baseline. Of course the ultimate conclusion to this discussion would be to consider how to integrate baselines with an organization’s efforts for continuous monitoring and automation.

This year one of my goals is to help auditors by providing them resources which will enable them to more efficiently create baselines of their systems and later automate checks of those baselines. To that end I’ve decided this year I will be releasing a number of scripts to help auditors perform baselines of their systems. The scripts that I will be releasing this year will all be Microsoft PowerShell scripts, but I may throw in a few Unix Bash scripts along the way just for some diversity. So enjoy the scripts and feel free to make requests. Most importantly we want to be able to offer resources that will help you in your efforts to better secure your systems.

Wishing you a Happy New Year and a Secure 2011!

Audit Checklists a Day: MySQL Database Audit Checklists (Week in Review)

Welcome back to our weekly archive of audit checklists! We hope these weekly lists will help you as you build your personalized checklist for auditing your own organizations. We know that sometimes it can be difficult to research each of these topics, so hopefully these lists will help save you some time when you are researching your audit scope.

In our last batch of posts we continued our month of database audit checklists with tweets focusing on MySQL database systems. This month we’ve tried to bring you a series of audit checklist for databases that would help you, regardless of the application system that is the scope of your audit. So many of the business systems we audit utilize databases as backend systems to support the application that we often find ourselves in the situation where we need to audit databases as well. I hope these MySQL checklists help (regardless of what Oracle decides to do with MySQL in the near future).

Also, while many of you on Twitter have already noticed this, we have been using a particular Twitter hashtag when posting our tweets. Each of our daily posts can be found using the hashtag #AuditChecklists.

If you have other similar checklists that you think are better, let us know, we’ll happily tweet them as well. This is a community effort, why not share?

Audit Checklists for Auditing MySQL Database Systems:

From Cert-in.org

From NGS Software

From the SANS Institute

From Webmaster2020.com

From MySQL

We hope everyone will enjoy and use these tools this week. If you have suggestions or ideas for future audit checklists or tools, please let us know, we’d love to hear your feedback.

Checklists a Day: Oracle Database Audit Checklists (Week in Review – April 17, 2010)

Welcome back to our weekly archive of audit checklists! We hope these weekly lists will help you as you build your personalized checklist for auditing your own organizations. We know that sometimes it can be difficult to research each of these topics, so hopefully these lists will help save you some time when you are researching your audit scope.

Last week we continued our month of database system audit checklists with a week of checklists on how to audit Oracle database systems. Like last week most of these checklists focus on the database server itself, and not the application code, database structure, or permission sets in the database. But at least these should serve as starting points for someone who is auditing technical controls on Oracle systems.

Also, while many of you on Twitter have already noticed this, we have been using a particular Twitter hashtag when posting our tweets. Each of our daily posts can be found using the hashtag #AuditChecklists.

If you have other similar checklists that you think are better, let us know, we’ll happily tweet them as well. This is a community effort, why not share?

Audit Checklists for Auditing Oracle Database Systems:

From the SANS Institute

From Oracle

From ISACA

From Vgrigorian

From Pete Finnigan

We hope everyone will enjoy and use these tools this week. If you have suggestions or ideas for future audit checklists or tools, please let us know, we’d love to hear your feedback.

Checklists a Day: Microsoft SQL Server Audit Checklists (Week in Review – April 12, 2010)

Welcome back to our weekly archive of audit checklists! We hope these weekly lists will help you as you build your personalized checklist for auditing your own organizations. We know that sometimes it can be difficult to research each of these topics, so hopefully these lists will help save you some time when you are researching your audit scope.

Last week we tweeted on audit checklists we thought might be useful when auditing a Microsoft SQL Server. There are so many MSSQL servers deployed today that is seems like you can hardly perform an audit without running into one these days. Maybe you audit a full blown instance of a server, or on the other hand maybe you only see SQL Express or the older MSDE installed. But still they seem to multiply like rabbits. So this week we tried to provide you resources to help with those audits. This also begins our month of database checklists. So every day (work day that is – please don’t make us tweet these on the weekends) – we’ll post a new checklist.

If you have other similar checklists that you think are better, let us know, we’ll happily tweet them as well. This is a community effort, why not share?

Audit Checklists for Auditing Microsoft SQL Servers:

Microsoft TechNet Checklist

Microsoft MSDN Checklist

Microsoft MSDN Checklist

TechTarget Checklist

SQLSecurity.com Checklist (Old Link Removed)

We hope everyone will enjoy and use these tools this week. If you have suggestions or ideas for future audit checklists or tools, please let us know, we’d love to hear your feedback.

Checklists a Day: Phone System Audit Checklists (Week in Review – April 5, 2010)

Welcome back to our weekly archive of audit checklists! We hope these weekly lists will help you as you build your personalized checklist for auditing your own organizations. We know that sometimes it can be difficult to research each of these topics, so hopefully these lists will help save you some time when you are researching your audit scope.

We focused this week on checklists to help assist you with your audits of phone systems this week. Some of the checklists focus on general audit techniques for phone systems and some of them are particular to Voice over IP systems. I hope these will assist you as you’re auditing more than just network devices. Enjoy!

Audit Checklists for Auditing Phone Systems / PBX / VoIP:

General PBX Audit

General PBX Audit (Old Link Removed)

General PBX Audit (Old Link Removed)

VoIP Audit

VoIP Audit

We hope everyone will enjoy and use these tools this week. If you have suggestions or ideas for future audit checklists or tools, please let us know, we’d love to hear your feedback.

DARPA & MIT Partnership – Example of “Leap-Ahead” Technology?

Yesterday, DARPA and MIT announced the results of a project that has been in development which would allow an organization’s network to function even while under an active attack from a distributed denial of service or similar attack. Overly simplified, it’s a network based, whitelisting solution with the ability to baseline normal traffic patterns and automatically block traffic if it detects that it’s under attack. Think of it like an advanced IPS on steroids.

TheNewNewInternet.com reported on it Thursday and stated:

“Previously, when a system was under cyber attack, the only solution to mitigate the threat was to take the server offline. However, there may now be another option. MIT researchers have developed a system that allows servers and computers to continue to operate even while under cyber attack.

The research, predominately funded by the U.S. Defense Department’s Defense Advanced Research Projects Agency (DARPA), has stood up to outside testing. DARPA hired outside security experts to attempt to bring down the system. According to Martin Rinard, an electrical engineering and computer science professor who led the project, the system exceeded DARPA’s performance criteria in each test.

During normal operations, the system developed by the MIT team monitors any programs running on computers connected to the Internet. This allows the system to determine each computer’s normal behavior range. When an attack occurs, the system does not allow the computers to operate outside of the previously determined range.

“The idea is that you’ve got hundreds of machines out there,” Rinard says. “We’re saying, ‘Okay, fine, you can take out six or 10 of my 200 machines.’” But, he adds, “by observing what happens with the executions of those six or 10 machines, we’ll be able to deploy patches out to protect the rest of the machines (http://tr.im/Sosj).”

So why is this all so interesting and worth repeating? I think this first of all a great example of a public / private partnership in the realm of cybersecurity defense. We simply don’t see enough of this kind of activity. Secondly, I have to appreciate their focus on an automated response to cyber attacks. This has been one of the major premises of the 20 Critical Controls / Consensus Audit Guidelines for quite some time and it’s great to see these groups creating solutions in that same spirit.

Finally I think it’s interesting in light of the mission of DARPA’s National Cyber Range project, which is:

“The National Cyber Range (NCR) is DARPA’s contribution to the new federal Comprehensive National Cyber Initiative (CNCI), providing a “test bed” to produce qualitative and quantitative assessments of the Nation’s cyber research and development technologies. Leveraging DARPA’s history of cutting-edge research, the NCR will revolutionize the state of the art for large-scale cyber testing. Ultimately, the NCR will provide a revolutionary, safe, fully automated and instrumented environment for our national cyber security research organizations to evaluate leap-ahead research, accelerate technology transition, and enable a place for experimentation of iterative and new research directions (http://www.darpa.mil/sto/ia/ncr.html – Link Removed from DARPA’s site).”

So is this an example of a “leap-ahead” research project? We might all have different opinions. But the bottom line is that it appears that the DARPA initiatives are moving forward. Let’s all hope this is just one of many more game changing technologies that we hope to see in the near future from these teams.

Checklists a Day: Virtualization Audit Checklists (Week in Review – February 22, 2010)

Welcome back to our weekly archive of audit checklists! We hope these weekly lists will help you as you build your personalized checklist for auditing your own organizations. We know that sometimes it can be difficult to research each of these topics, so hopefully these lists will help save you some time when you are researching your audit scope.

We decided to hit another hot topic this week, so we decided to talk about virtualization. I mean, when you’re not talking about cloud computing security over the family dinner table, you’re probably most likely talking about virtualization security and how it impacts your daily lives (Honey, can you install that new garbage disposal? Of course I can dear, but couldn’t we just virtualize it?). So we’re hoping that these audit checklists will help you as you’re evaluating the controls that protect these environments. You know you’re using them, might as well protect them!

Audit Checklists for Auditing Virtualized Environments: 

DISA (Old Link Removed)

Tripwire (Old Link Removed)

VirtualizationAdmin.com

Microsoft

DarkReading

We hope everyone will enjoy and use these tools this week. If you have suggestions or ideas for future audit checklists or tools, please let us know, we’d love to hear your feedback.

Checklists a Day: Cloud Computing Audit Checklists (Week in Review – February 15, 2010)

Welcome back to our weekly archive of audit checklists! We hope these weekly lists will help you as you build your personalized checklist for auditing your own organizations. We know that sometimes it can be difficult to research each of these topics, so hopefully these lists will help save you some time when you are researching your audit scope.

For this week’s checklists we’re going to be returning to the world of more operational controls. Specifically we’ve been investigating audit checklists for evaluating cloud computing environments. Come on, we know you’ve been thinking about it and talking about it both in your IT departments and in your corporate board rooms. Heck, you’ve probably been chatting up other parents at your kid’s little league and talking with them about it! So this week we’re listing off some helpful checklists we’ve found for auditing cloud computing environments. Enjoy!

Audit Checklists for Auditing Cloud Computing Providers: 

ENISA

Cloud Security Alliance

Grid.org.il

SNIA (Old Link Removed)

FUMSI

We hope everyone will enjoy and use these tools this week. If you have suggestions or ideas for future audit checklists or tools, please let us know, we’d love to hear your feedback.

Searching for Hashes of Malicious Files (APT – Aurora)

A couple weeks ago I posted a blog article with some sample file hashes and domain names associated with the recent Google hacks (think APT or Aurora).

Since then I’ve had quite a few people ask me, if you have a system that you suspect might have been compromised, how do you search that system for files that are malicious if you have a list of hashes that you know are malicious? In other words, you have a list of hashes and you want to know if there are any files on your file system that has the same hash value.

Disclaimer – before we continue you should know, hashes of malicious files are just one way of attempting to discover if your system has been compromised. Especially when dealing with a threat like APT, which is highly intelligent and adaptable, you have to know that if the threat knows that you’re on to them and that you’re looking for a specific set of hashes, that they’re smart enough to adapt. What will they do, they’ll change their malicious files so the hashes change as well. There’s no doubt this is a limitation. But utilizing the technique we’re about to describe you can at least start to eliminate some of the low hanging fruit. You may also want to investigate the projects involved with fuzzy hashing. This may be an alternative to some of the standard techniques described here.

Ok, now that you’re ready to start examining your systems for malicious files, here is a process to consider:

Step One: Assemble a Text File of Known Malicious Hashes. The first step you need to follow is to gather a list of hashes of known malicious files. This will be the list of hashes you’re scanning your system for. Remember, the value of your scan will only be as good as the list of hashes you have. A starter list of MD5 hashes is currently being hosted at Enclavesecurity.com and can be found here if you’re looking for a list to get you started. This list certainly is not comprehensive, but at least is a place to consider building your first list from.

Step Two: Decide Which Hashing Tool to Use. There are a number of good tools that you can use to scan your system and to generate hashes of all the files on your file system. Many of these tools are commercial and there are open source tools for this as well. On the commercial side tools like Tripwire, Lumension, and Bit9 are quite effective at this. There are certainly others, but many of you are already using these tools, so you might as well take advantage of them. Unfortunately there are also many of you that simply cannot afford these tools. If you’re looking for a good open source tool to use to start scanning your systems, let me recommend MD5Deep. This is a tool in the public domain that is especially useful for this purpose. While there’s not enough time in this post to talk about how to use the tool, we’ll post more on it later. You could also consider rolling your own scripts, using PowerShell or shell scripting to generate these hashes as well (but I still recommend MD5Deep – it’s cross platform, supports recursive file scans of directories, and natively interfaces with a number of hash databases).

Step Three: Scan Your System. Now that you have your list of hashes for malicious files and you have your scanning tool, now it’s time to scan your system to see if any files with these hashes exist on your system. This is the basic part of the exercise – do you have malicious files on your system or not? Depending on the tool you’re using this process will be slightly different, but in the end you’re trying to determine if you have a compromised host. Auditors – you should be asking companies the control question, if law enforcement approaches you with a list of hashes like we’re describing here and they say you need to check your system to see if any of these files exist on particular hosts in your environment, how would you look for the hashes? Ask to see their process in action (we want more than tabletop reviews here).

Step Four: Automate System Scans. Finally once you have your tool working in a manual mode, automate the scans. This is one of the major principles of the 20 Critical Controls / Consensus Audit Guidelines that we talk so much about. Manual scans are fine when you need to use them – but how much better is it if you could implement a tool that would be constantly scanning your systems and would notify you one of the hashes were discovered? Automation is key.

While there are certainly other ways to go about looking for malicious files on your file system or indicators of compromise on a system, examining file hashes certainly has to be part of your arsenal. If you’re auditing a system, knowing that you have a control in place to scan for signatures of known bad files has to be part of your toolkit. Traditionally we’ve done this with anti-malware tools, but unfortunately many of the large anti-malware vendors still don’t let you know which hashes they’re scanning for and they don’t give you the ability to add hashes that you’d like to scan for in their tools. Thus we’re left to our own devices to discover if files with these signatures are still on our systems.

Hopefully putting this tool in your toolkit gives you one more angle to consider when looking for indicators of a compromise on your systems.