Epitaph of Entropy

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.