• In IT there are certainly enough terms and terminology to confuse even the most studious and astute of us. Add into the mix the standards, acts, laws et al that need to be considered in relation to security testing and the mix certainly thickens.

    To help out here’s a quick listing of those that we often come up, with some handy links.

    Remember, many of these are not going to apply to your organisation, either because they are US standards or for a different industry sector for example. However, conversely you may need to consider several of them. For example if you are in banking and finance and you hold credit card data you may need to look at SOX, PCI-DSS and GLBA.

    We need to know what these acts, standards and benchmarks require in order for an organisation to declare itself compliant to them. In addition you’ll want to factor into your security and compliance testing guidelines from vendors and your own internal standards.

    The Test Hats Security Team are experienced in guiding clients through the compliance and auditing process. We have helped build or refine a number of Information Security Management Systems and Security Auditing programmes. Why not get in touch today to see how we can help you.

     

    Security Related Acts, Standards and links to information

    BASEL II               

    Bank for International Settlements - Revised international capital framework

    http://www.bis.org/publ/bcbsca.htm

     

    CIS Benchmarks

    Center for Internet Security. Various standards

    http://www.cisecurity.org/

     

    COBIT

    Control Objectives for Information and related Technology

    http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx

     

    DISA STIGs

    Defence Information Systems Agency - Security Technical Implementation Guide

    http://en.wikipedia.org/wiki/Security_Technical_Implementation_Guide

     

    FDCC

    Federal Desktop Core Configuration

    http://nvd.nist.gov/fdcc/index.cfm

     

    FIPS-199

    Federal Information Processing Standard

    http://www.itl.nist.gov/lab/bulletns/bltnmar04.htm

     

    FISMA

    Federal Information Security Management Act

    http://searchsecurity.techtarget.com/definition/Federal-Information-Security-Management-Act

     

    GLBA

    Gramm Leach Blily Act (Not Graham Leach Bailey act)

    http://www.ftc.gov/privacy/glbact/glbsub1.htm

     

    HIPAA

    Health Insurance Portability and Accountability

    http://searchdatamanagement.techtarget.com/definition/HIPAA

     

    ISAP

    Information Security Automation Programme

    http://en.wikipedia.org/wiki/Information_Security_Automation_Program

     

    ISO-17799:2005

    Information technology - Security techniques -Code of practice for information security management

    http://en.wikipedia.org/wiki/ISO/IEC_27002

     

    ITIL

    Information Technology Infrastructure Library

    http://www.itil-officialsite.com/

     

    NERC CIP

    North American Electric Reliability Corporation - Critical Infrastructure Protection

    http://searchcompliance.techtarget.com/feature/What-is-NERC-CIP-and-ITs-role-in-critical-infrastructure-protection

     

    OMB M-07-11

    Memorandum on security configurations Re; upgrading from XP to Vista

    http://www.whitehouse.gov/sites/default/files/omb/assets/omb/memoranda/fy2007/m07-11.pdf

     

    PCI – DSS

    Payment Card Industry - Data Security Standards

    https://www.pcisecuritystandards.org/security_standards/

     

    SCAP

    Security Content Automation Protocol

    http://scap.nist.gov/

     

    SOX

    Sarbanes-Oxley Act

    http://searchcio.techtarget.com/definition/Sarbanes-Oxley-Act

     

    SP 800-70

    Special Publication 800-70. Security Configuration Checklists Program for IT Products

    http://checklists.nist.gov/docs/SP_800-70_20050526.pdf

     

    The Test Hats Security Team

     

     

     

  • Deciding that your organisation needs to have a Penetration Test conducted is a great step forward to ensuring overall security of your network. You’ve no doubt carefully considered why you want to conduct penetration testing and identified a range of security goals you want to achieve. Overall the goal will be to ensure the network is secured from potential intrusion and possibly a specific application you’re deploying is secure from unauthorised use and can’t be leveraged to enable exploitation.

    Now you’ve decided what you want doing, engaging Test Hats to perform the penetration testing is the wise next step. Our team stand ready to deliver Application Vulnerability Assessments and Penetration Tests for your project. From our fully equipped Test Lab our security technicians can plan and execute the right level of testing to ensure the security of your network and application.

    An initial step we take is of course to identify the ‘project sponsor’ who is the responsible authority within your organisation that is requesting and can authorise the penetration testing. This is often not the same person and so we need to ensure we’re clear on this. Very often a Project Manager will request penetration testing at the behest of a Test Manager, but someone like the CTO or Head of Operations needs to authorise.

    However, even with relevant authority given to an approved request, there is still another key consideration and that is around data. Before we commence penetration testing we’ll ask two key questions that are often forgotten;

    • who owns the network that will be the subject of the Penetration Test?
    • who owns the data residing on that network?

    At first thought it might be assumed the network and the data residing on it must have the same owner, but it may not be so simple. In a typical organisation someone like the CTO might own the network for the organisation, perhaps managed day to day by a Head of Operations or similar.

    Data however needs to be looked at more closely. It isn’t sufficient to say the organisation itself owns the data on a network even if legally this may be the case, which it might not. Even where data is owned legally by the organisation it is owned/used day to day by many departments. In the course of penetration testing the Test Hats security technician may access HR systems, Sales Intranets or Support Extranets for example, all of which contain data that may be confidential and in use by those departments.

    It’s essential that a) the scope of the penetration testing is clear before testing commences, and b) the departments that are in scope of the testing are told^ their data may be exposed.

    Who owns the data?

    The final thing to consider is whether the data in the network actually belongs to the organisation. There is usually an assumption it does but unless company policy states this as the case, some data may be considered private. Take emails for example, unless a company policy exists that states private emails sent over the company network are company data, they must be considered private.

    While it’s generally accepted that employees have a limited right to privacy when using company provided computers and other devices the organisation should cover this point with policy and contract terms. Test Hats recommend that a clause is in place in the employee contract or an addendum issued, that covers the ownership of data and the right of the organisation to monitor and review the data, even where this may be considered personal data. An alternative approach is to refer to a robust IT Policy which contains the details and clearly covers these points. With this in place it will be easier to set a clear scope for the penetration test and know that any data accessed is the property of the organisation.

    If you have any queries or questions about the points raised in the blog post or about penetration testing in general then please get in touch.

    The Test Hats Team.

     

    ^ Departments may be told of the testing that will take place but possibly not when it will be done. This depends on whether you have requested Test Hats to perform blind, double-blind, etc.

  • Over here at Test Hats Towers (hey, it's a 6 story building we're in and our bit is called Portal 7) we've donned our super hero cloaks and decided to get on a bit of a mission.

    That mission is to get 'regular' functional / system testers to look more closely at security related testing. Now, security testing is a big field and we're not expecting testers to suddenly master the entire domain. One responsible step at a time, but steps none the less and not the complete avoidance of security testing we seem to see now.

    This is the issue we have, too many competent testers are avoiding security related testing altogether. There really is no need for this and as we'll outline below, it's a dangerous state of affairs. As with everything there are some caveats however. The main one is that old-school test case driven testers probably aren't going to do well, perhaps at auditing, but we're talking about testing. The preference is for people who have practiced exploratory testing, those are who we want to speak to. We want to talk specifically about Application Security Testing.

    Our Argument

    It’s our contention that testers who practice exploratory testing techniques have learned a number of essential skills for testing in a security context. Being guided by test conditions but driven by heuristics. Thinking, observing, questioning, reasoning and testing ideas and insights, applying knowledge, acting on new information as it arises. These are essential skills for a security tester and those who regularly practice exploratory techniques are well equipped, technique wise if not domain knowledge wise, to test in a security context.

    However, we also contend that security testing is seen as an exotic and separate field to application testing, and as such many testers avoid testing related to security.

    We believe this is both and unfortunate and concerning state of affairs. With the continual rise in Cybercrime and growing threat from Hacktivist groups, such a Lulzsec and Anonymous, it’s essential that competent testers skill-up in security related testing. As the web becomes ever more part of how the world connects, security becomes even more of a global concern.

    How To

    One way is to attend the Weeknight Testing session later this month, on the 21st September. The other is to take part in our Security Testing Group over at the Software Testing Club where we're talking about all things testing.

    The most important thing to do is start using your testing skills to test in a security context. We'll be talking more about that in subsequent blog posts and forums.

     

  • This afternoon we saw yet another list of user names, email addresses and passwords published in retaliation by the hacktivist / hacker group Anonymous. This time it’s the turn of the Bay Area Rapid Transport System (BART), http://huff.to/BayHack.

    The list is over at http://www.djmash.at/release/users.html and will no doubt be taken down very soon. Here’s a screen shot in case (Warning, some coarse language!)

    BART - Anonymous message

    Why are we highlighting this one? Yet again you look over the list and it’s obvious people are not taking password security seriously, that’s our Topic of the Day at Test Hats today.

    With passwords like river, love, Amanda, Sheryl, bart, MyBart, 1212 and 345345 the users are seriously risking getting hacked. There’s a high chance many of those Gmail, AOL, Yahoo and Hotmail accounts are using the same password on those services as for the BART system.

    The worst one we spotted was similar to “Dave Scott”, who had an email similar to scotty_98@yahoo.com and a password of… you guessed it scotty. Way to be social engineered Scotty! (names changes to protect the innocent, kinda).

    The Test Hats Team

  • This morning at Test Hats we started building our database of MD5 password hashes and cracks, to help with our Security Testing engagements.

    As part of populating this database, we’re loading, encrypting and decrypting password lists. Some of these lists are available from sources such as Imperva, others from various forums and hacker / underground groups we’re part of.

    As some of the lists are large, never smaller than say 8-10k passwords in a huge Excel or Text file, it takes some time to go through. That’s where automation comes in handy of course! However, curiosity always creeps in and there’s always the desire to have a look yourself at what passwords people are choosing.

    I wrote a little Ruby script to pick out some passwords and parse them for similar characteristics. I decided to pick the name ‘Robert’ from one list and look at how often it came up and in what format. For completeness this includes; Robert, Roberta and Roberto.

    Chart - Robert within a password

    Chart 1: Prevalence of different password structures with ‘Robert’ as the root

    We’ll assume that the user choosing the password is called Robert, not exactly the first step in picking a secure password! Let’s look at each of the items in the chart above, working clockwise from the bottom.

    Name + Number (54%)

    The unsurprising thing from this small sample is more than half of our Roberts just added a number on the end of their name. These came out as robert01, robert99, robert890, etc. Absolutely rubbish in terms of security as a simple script or cracking tool will find these in seconds.

    Name + Character + Number (9%)

    Some of our more creative Roberts decided to add a character in with their name  and number to make the password a bit harder to guess. Examples included robert08!, robert1a and Robert7R. In this category we also saw some others such as Roberto@, Roberto_02 and slightly more inventively robert4ever4. All of which are going to add maybe 1 to 2 seconds onto how long it takes to crack the password.

    Name + Word (2%)

    The category with the smallest number of examples was where Robert added another word onto the end of their name. Here we saw robertisawesome and the ultra-secure roberetqwerty. The best though was perhaps a Robert with a sense of the ironic, robertlolffs.

    Name + Year (7%)

    It’s hard to recall how many times we’ve been told that passwords, pin numbers and other passcodes of various varieties should NEVER have your birth year in. Yet I’m guessing some Roberts have done just that. In this category we see 22 examples that include: robert1977, Robert 1981 and just to make it easy to remember (and guess), robert2011. These are even easier to crack that adding random numbers at the end and risk giving away a second piece of Personally Identifiable Information (PII).

    Name Only

    The last category is where Robert decided to use what appears to be their name only. We have to let you know RobertDaniel, RobertGouldshaw and worst of all, RobertPeterWilliams… and the other 85 Roberts that took this approach, this really isn’t a good idea for your on-line security!

    Wrap-Up

    We see time and again that passwords chosen by users are often very insecure. Worst still, users reveal personal information about themselves, via their passwords, that would be a great help to hackers.

    It’s essential that when choosing passwords they are:

    • Complex – containing combinations of words, characters and numbers
    • Lengthy – the longer the password, the harder to crack
    • Obscure – do not have any Personally Identifiable Information (PII) within them
    • Unique – are used in one place only
    • Secret – of course, they need to be kept secret too!

    Always choose secure passwords, use an online tool to create one if you’re having trouble and remember to change them every few months or so!

    The Test Hats team.