Epitaph of Entropy

Way back in June of last year I covered the process and resources I use to build hardening templates for operating systems and applications.  While that article alone would be good enough for an administrator, coming from the security side we also need to be able to easily audit and assess compliance with the template specific to our company. While there are many ways to tackle this issue from a more administrator level such as using a system configuration management system like Puppet, Chef, or CFEngine on POSIX and Microsoft System Center for the Windows world (and I guess the Microsoft Baseline Security Analyzer) the scope of this post will be limited to tools that can audit both of these, in an automated and hopefully quick method.

The first way you could do this for any operating system is via custom scripts.  With POSIX operating systems being text based, as long as your familiar with parsing text and regular expressions, you can easily get any information you'd like from a target system.  You could run this script via an SSH key trust to automate it to every system and a pre-defined time.  The Windows equivalent could be a PowerShell script or VBscript ran with Domain Admin/Local Administrator credentials.  Both of these require time to develop and maintain.

Fortunately for those of us who's jobs don't allow us to spend as much time as we'd like on developing solutions ourselves, there exist some paid products that can help us out.

The first I'll mention is a tool you probably already use, Nessus.  Included with your ProfessionalFeed subscription you can login to the Support section of the site and they have a list of a number of .audit files particular to certain auditing standards.  These include things like PCI-DSS, HIPAA, as well as hardening guides from the NSA and CIS (two of the resources you should be consulting when designing and updating your hardening templates).  The .audit file format is fairly easy to understand and you can customize it to your specific requirements pretty quickly.

The second is CIS-CAT, offered to members of the Center for Internet Security.  This tool I like a bit more than Nessus in that it does more than just provide a pass or fail grade, it includes context for the settings and usually some reasoning why they recommend it or how to figure out how you should set it.  I also like the percentage it offers, while not necessary and its unlikely you'll ever see all 100%'s even with a well customized audit, it gives you a metric to make sure you don't drop below.  This tool seems a lot more customizable, though it does require a local installation on most of the devices.

Those are the only two I've really seen that provide value in this space, if your aware of any others, specifically free ones as I'm surprised there aren't any out there, please leave a comment.

So, now that we have a method for auditing, lets talk about expectations.  In my opinion, a system should be audited after initial build before being put into production (an active participant of a network), as well as after every patch cycle for that particular machine.  If you work at a place that patches very rarely, I'd at least set a threshold of 60 days for all systems, as this could be an indicator of a breach.  Obviously how you audit is up to you, someplaces like to test everything, some like to take a random or alternating small sample.

Once you've found a metric that was passing that no longer is, it needs to be treated as an incident unless it is the outcome of an approved change via change control.  You won't be your administrators best friend anymore, but sudden changes in configuration are often your first indicator of a breach, just as well as a misconfiguration done in error that could be costly if not detected and reacted to quickly.

If any of this seems like it wouldn't work in your environment, let me know why, or if you handle it in a different fashion then I've mentioned I'd also like to hear about that as well.

While I am a fan of embracing these ideals in general, this article is directed specifically at using the ideals of the punk rock movement to improve your security program.  I came upon this idea after hearing that our budget had gotten slashed yet again, despite demand and risk vectors increasing.  While not everyone will be in the same situation, I do believe it never hurts to embrace these.

• Non-conformity - If you've attended a security conference recently you've heard the example that there are no silver bullets in security.  Its a fact that while depressing, and in spite of the number and cost of commercial products increasing annually, cannot be ignored.  My example of conforming when it comes to security is adopting a program that is focused solely on compliance check marks, and less on widespan comprehensive programs that product what is truely valuable to the company. 
  
  Magazines, vendors, and even the buzzwords that senior level management are fed all lead to directives to buy more to meet a checkmark, when really we are inundating ourselves with products that hardly work, despite their adding additional load onto what we're expected to do every day.  Until there is mass adopting of the ideas starting to be spread by the Penetration Testing Execution Standard, your program is better off not to follow suit.  If you do conform your spending hundreds of thousands of dollars to comply with regulations that are too lose and don't really protect your assets.
   
• Lo-fi - One of the greatest aspects of the punk rock culture is that you don't have to have expensive gear or tons of experience to participate, just the drive to contribute and make yourself heard.  I work in an understaffed team due to budget constraints, which leads to the jack of all trades master of none pitfall.  We need to convince our management to let us change our ways so that we do have the expertise, but to do this without additional staff or budget, we rely only on our drive to keep up.
  
  When you have a smaller staff, its easy to see that management would rather spend money on expensive pre-packaged solutions than on staff, because at the end of the day they only care that they can be compliant.  I'm recommending that you add in part of your evaluation process that asks the questions that aren't typically asked.
  
  1. How many staff members will we need to administer this?
  2. How customizable is the product, can it be tailored to meet our needs or interact with existing infrastructure?
  3. Does it have an API that we can leverage to allow for it to completely meet our needs instead of only meeting 60-80% of them?
  
  Asking questions like these (assuming you get honest answers back) allow you to weigh the options better.  Would it be more cost effective to leverage existing open source projects and a little development time to create your own solution?  While management doesn't always support development during busy schedules, any solution that you acquire will have time and resources dedicated to learn, implement, and administer it.  You may find in some cases its easier to dedicate one person to developing a solution for a week rather than tying up different groups over the same amount of time to get a product integrated.  Lo-fi is lower cost in terms of time and money, and usually solutions that you create or leverage on your own don't leave you stranded when you need that extra 20-40% of features that commercial offerings aren't providing you.
   
• DIY - The reasons above all lead into do it yourself.  No two companies are the same (with the exception of chains with branches).  As such, why do we allow vendors to sell products to us with examples that the solution works great for a list of other companies?  One thing that didn't jump out as obvious to me until recently is the vendors that do show their client lists, don't be wowed by the client, consider what their security budget is compared to yours.  Takes yours divided by theirs and you get a percentage.  While rough and without hard numbers, I propose that this percentage represents the products effectiveness in your environment.
  
  We've allowed the industry to mold security teams into looking for solutions that instantly resolve issues, despite knowing that the attacks that are more likely to cripple the business won't get stopped by one piece of protection alone.  To achieve proper protection, you have to build your own solution.  I'm not opposed to utilizing products in your own solution, so long as it has other parts.  The overall solution should be your design, for every service you need to provide, or protection you need to ensure.  You likely won't have time to develop your own anti-virus, but you might have time to write some code that passes potential at risk files through multiple scanning tools to get more complete results.

On Wednesday I participated in Hurricane Lab's Hack for Hunger event.  I was able to come in second place, losing only to my former boss and friend.  After talking to a few other participants afterwards, a few things became very clear and I thought I'd share what I learned.

1. Unix system administration experience is priceless
   
   My friends success was largely due to him approaching the challenge not from any penetration testing methodology, but if I ran these services this is what I would have locked down.  This experience played into #2
    
2. Old school exploits and common misconfigurations are your friend
   
   I think in my case, my work environment being very up to date and always patching has pigeon-holed me into a default assumption that only newer attacks need be tried.  Its really hard to flip that switch and start with issues from 10-15 years ago and progress to more recent exploits instead of working my way backwards.
    
3. For binary anaylsis / reverse engineering challenges, you often only find the key if you don't think too far into it
   
   This one is kind of true to life.  Occassionally you get the reward of grinding on something for hours and finally the hard work pays off.  Even more often however is the head slapping moments where you spend a few minutes on something and it almost seemed to be too easy.  These happen to occur the most in real life, so the only excuse I have is assuming they were be more difficult by default.
    
4. With such a short challenge window, you have to the vulnerability assessment tool
   
   Usually at least 25-50% of a challenge will be issues a vulnerability assessment tool would catch.  The problem is you have 3 or fewer hours normally to complete the challenge, and while in some cases thats enough time to finish the scan, you don't want to be waiting half the challenge for those initial results.  The fix to this is have scripts ready to go to cover the basic issues.
    
5. If you pentest for a living, you need to flip that switch off
   
   I say this because typically when you pentest for work, you have a lot more time to work with, and you likely have your methodology and process pretty well defined.  When you have only a couple hours to find as much as you can, methodology and process kind have to be redefined or go out the window.

"Good artists copy, great artists steal" --Steve Jobs

The same can be said about programmers, although being held to a different standard.

For artists, their work is appreciated with the sensoratory system, while programmers have the luxury of having their code in the background, in a lot of cases requiring some reverse engineering to get a clear picture what it was to begin with.

I think this statement is as much as turning someone elses idea into your own as it is an ode to productivity.  Obviously if you can reuse your code, borrow and modify a function that would take hours to write, your going to reach project completion faster, and as such look better.

The only real difference that works against this idea is for an artist to steal, they usually have to have an immense amount of talent, replicating a classic painting for example requires hours of studying the strokes, experimenting with different washes or oils, it takes a highly skilled craftsman to pull it off well.

In the case of coding, more and more we see all out copy and pasting, and when auditing the code further it can become evident that there isn't that high skill involved, its merely combined plagarism.

The goal with producing anything is to improve yourself, and put your product out there to be criticized (that statement just resonated with my BFA degree a bit).  Its always okay to find a reference for something you are stuck on.  The mantra however should be find, refine, reuse.

FIND - Find the example code that best suits what you need to do.

REFINE - Refine your understanding of how it works, and more importantly, how it works in the greater scope of your project.

REINVENT - Anyone can copy and paste and modifying the existing code body to allow for the borrowed sample, craftsman can reinvent code, or look at the source for an idea of the logic involved and write something similar that matches the code body.

Without this attitude, we're settings ourselves up to have vulnerable code, much like using existing libraries, once someone finds a vulnerability in just one thing you've borrowed or included, they own your app.  Also, without developing and pushing that understanding of programming, nothing is gained.

Let's apply this a bit further.

Look at Microsoft.  Occassionally code vulnerabilities will affect almost every known version of Windows due to their reuse of libraries from decades ago.  While this reuse is likely to save time and money, reinventing those libraries every once and a while would cut down the risk substantially.

During a recent assessment I was able to upload a meterpreter ASP payload and execute it on an IIS 5.1 system.  getuid showed that I was IWAM_systemname and attempts to escalate privileges with both getsystem and the AtAbuse meterpreter scripts were not providing escalation.  After some googling I stumbled across the idea to pivot to localhost.

This idea blew my mind in two ways.  First, the amount of vulnerabilities grows substantially when you have access to services listening on localhost, and in most cases interaction with them bypasses any safeguards put in place like a firewall, in the assessment case I was able to pop the box with MS08-067. Secondly, why would a company (Microsoft) go to such lengths to restrict a service to a jail, but allow that user to have routing privileges?  I get it, it is an internet service, it needs to have access to networking to create listeners and potentially do routing, but still.

Anyways, wanted to document this so I don't forget it.  Hopefully a lot more of these will be posted in the future. 

A good configuration should take the entire life of the machine into account.  It should start with BIOS or EFI settings, lay out the process for installation or imaging, cover base software installation, describe configuration changes to harden the OS and application, and incorporate commands or instructions to validating these changes on a recurring basis.  Ultimately you should have a document, perhaps one per operating system that describes the standard build and hardening of a machine from it arriving to it rolling into production.  Once this document is created, exceptions to this standard can be clearly documented so a configuration trail can be created by combining the build document with the exception ticket.  Make sure you include the version of the configuration document in the exception ticket so you can easily track back exactly what was done to build out the machine/device when it was originally configured.

One of the biggest challenges when creating a hardening guide is finding the best practices.  Every system administrator has their own idea of how to harden a server dictated by industries they've worked in, their IT background, and their work ethic.  The same is true with security professionals, so it is necessary to start with a neutral baseline. To assist with this gap I recommend starting with best practices from various parties.  I like to start with the NSA Operating System Guidelines, though it is worth noting they do not have material for all operating systems. Next, I add in recommendations from the Center for Internet Security (CIS) Security Benchmarkswhich cover a wider range of operating systems and applications. After that I check theNational Vulnerability Database (NVD) National Checklist Program Repository hosted by NIST as they tend to aggregate material from both of the prior sites as well as other reliable sources. Finally I search the papers on SANS Information Security Reading Room as some of the certification holders have written great papers on securing both operating systems and applications.

After creating a baseline its great to add in the tuning that you've picked up in your experience, and gives you an opportunity to meet with the system administrators and record changes they typically make.

Now comes the fun part, combine both into one document and present it to both the administrators and management to discuss the settings your recommending and their justification.  Note and objections or changes and update the document with a new version to add the changes in.

Review these at least annually as service packs and updates can create drastic changes in security.

Components of a Configuration guide:

1. Any pre-bootloader changes include BIOS, EFI, RAID, etc.
2. OS install instructions
3. Applications to be installed, possibly sorted by machine function
4. Hardening guidelines starting with OS and including applications 
5. Instructions for validating the configurables
6. Ensure exceptions are documented in the ticket for the device/machine
7. Regularly validate the configuration, this should be automated if possible 

Over the past decade I've tried and failed to maintain a number of websites to both post my thoughts and try to get some more attentions for projects my friends have done.  It seems like things always start off pretty well and then taper off with me forgetting to keep up.  I've decided I'll maintain the few side projects I have on their own but use the importing capabilities of Virb to create one place that consolidates everything.

I'd like to say that this is the beginning of something new and to check back often for updates, but honestly lets see where this is at in about a week.  What I can tell you is if I do update as I hope to you can expect a wide mix of content but currently it will likely be primarily mobile application development and information security related.  I also am going to try to have this be an archive of the great things I've found, and try to maintain a list of must see movies, must listen bands, and links to all the sites I find useful.