Author Archive

This week’s blog post was inspired by camokatu‘s question on what to do when a Utility company doesn’t hash passwords in their database.

It seems the utility company couldn’t understand the benefit of hashing the passwords. Wizzard0 listed some reasons why they might not want to implement protection – added complexity, implementation and test costs, changes in procedures etc. and this is often the key battle. If a company doesn’t see this as a risk they want to remediate, nothing will get done. And to be fair, this is the way business risk should be managed, however here it appears that the company just hasn’t understood the risks or isn’t aware of them.

Obviously the consequences of this can range from minimal to disastrous, so most of the answers concentrate on consequences which could negatively impact the customer, and the main one of these is where the database includes financial information such as accounts, banking details or credit card details.

The key point, raised by Iszi, is that if personally identifiable information is held, it must be protected in most jurisdictions (under data protection acts), and if credit card details are held, the Payment Card Industry Data Security Standard (PCI-DSS) requires it to be protected. (For further background information check out the answers to this question on industry best practices). These regulations tend to be enforced by fining companies, and the PCI can remove a company’s ability to use credit card payments if they fail to meet PCI-DSS.

Does the company realise they can be fined or lose credit card payments? Maybe they do but have decided that is an acceptable risk, but I’d be tempted to say in this case that they just don’t appear to get it.

So when they don’t get it, don’t care, or won’t respond in a way that protects you, the customer, what are your next steps?

from tdammers – responsible disclosure :

Contact the company, offer to keep the vulnerability quiet for a limited amount of time, giving them an opportunity to fix it.

In the meantime, make sure you’re not using the compromised password anywhere else, make sure you don’t have any valuable information stored on their systems, and if you can afford to, cancel your account.

from userunknown –

contact their marketing team and explain what a PR disaster it would be if the media learnt about it (no, I’m not suggesting blackmail…:-)

from drjimbob – 3 excellent suggestions:

Submit it to plaintext offenders?

Switch to another utility company?

Lobby your local politicians to pass legislation that companies that do not use secure hashes (e.g., bcrypt or at very least salted hash) on their password data are liable for identity theft damages from any compromise of their systems?

But in addition to those thoughts, which at best will still require time before the company does anything, follow this guidance repeated in almost every question on password security and listed here by Iszi –

Use long and complex passwords for all websites & applications, and do not re-use passwords across any websites & applications. Additionally, limit the information you give these websites & applications to only that which is absolutely necessary for them to serve their purpose

You may have noticed all the blacked out sites on the Internet on the 18th of January, but possibly aren’t aware of why they were doing this. The answer is SOPA – the poorly named “Stop Online Piracy Act”

In itself, that sounds fine, right? We want to cut piracy so this must be good. Well, no.

We already have laws in many countries which already allow us to take down websites hosting pirated content, but in many countries the process is one of “Innocent until proven guilty” – this means evidence needs to be provided, legal processes have to take place, and a court can rule that a website must be shutdown. The DMCA lets the US do that.

What SOPA does is change the balance to “Guilty until proven innocent” – which means that a website can be taken down just because of an allegation of copyright infringement.

For StackExchange, for example, occasionally people post plagiarised content. We rely on the community flagging this content, and moderators then remove it as fast as possible. (Look at Joel’s answer to this question to see the full process under DMCA and how this protects StackExchange legally). If SOPA was in force, StackExchange would be in danger of being removed from the Internet for any violation as it would be seen as guilty.

And this holds true for websites large and small – personal blogs, comics, Wikipedia, Reddit, Google and many others.

What is also very worrying is the US’s history of going after individuals in other countries citing US law, when those individuals have no connection to the US. See Richard O’Dwyer’s case – while what he did may have been used for nefarious purposes, all he really provided was links to other websites, and yet the US have forced the UK to extradite him. With a significant portion of the Internet under some US control, it wouldn’t be stretching the truth to assume this US bill would affect many other countries.

Another outcome if SOPA came into force would be an acceleration of businesses away from networks owned or controlled by the US, which may directly lead to greater piracy threats.

The Electronic Frontier Foundation – a strong force for free speech on the Internet has this handy guide to SOPA. 

So why didn’t StackExchange join the blackout? – see this answer:  the content is owned by the community, so the entire community would have had to agree on the blackout.

Have a look at this video by Fight for the Future or this awesome TED talk for some further info.

This week’s question was asked by mdegges – What is the difference between $200 and $1,000+ firewalls?

This sparked some interesting discussion, as well as making me think quite deeply about it. In general, like many other IT people, I see enterprise level firewalls in my day job and run cheap SoHo firewalls for my home network and while it makes sense at these two extremes that there would be cost differences, what are the actual differences in practical terms?

tylerl flagged the two most important differentiating factors for an enterprise, and they aren’t even security features

• bandwidth
• latency

In addition Paul listed the number of concurrent connections as a third factor. Again, this is not a security feature.

For an organisation with thousands of connections or large data flow this makes perfect sense – you can’t allow the security device to become a bottleneck which hampers your business.

So does this just mean that you are paying for the firewall to be faster?

No –  there is more to it than that:

SoHo firewalls tend to be very simple – applying rules based on source or destination address, port and protocol, sometimes with some intelligence around matching responses to requests, whereas enterprise-grade firewalls often have deep inspection capability. tylerl gave some good comments around this functionality.

Paul also described the different frameworks – with home firewalls usually being single function devices, and enterprise firewalls providing multiple features dependent on licence, including IPSec, VPN etc.

David also pointed out a final factor that is very important for large organisations – availability. So firewalls at this level need to have High Availability or cluster capability to minimise downtime.

As a quick summary then, the difference is mostly about speed, with a few extra security capabilities.

If you have more information on other differences, please add an answer of your own over on http://security.stackexchange.com/q/9409/what-is-the-difference-between-200-and-1-000-firewalls

I prepared this presentation for an ISACA event and realised it is applicable to a much wider audience:

The business benefits of virtualisation are fantastic in terms of costs savings, agility in delivering services and business resiliency.  It enables organisations to spend less on hardware assets  and use their existing hardware more efficiently by running multiple machines on a single piece of server hardware without significant degradation in performance. Industry and vendor studies indicate up to 50% savings in IT expenditure.

An organisation can also run just the number of servers they need at any time, with demand led increases possible at short notice simply by enabling a new virtual machine. This is a further driver for virtualisation today as data centre power costs are significant to any large organisation and a reduction in the number of servers needing power and cooling offers a direct saving in bottom line costs. Studies indicate savings in energy costs through server virtualisation can reach 75% for a typical mid-sized organisation.

What are the risks?

Segregation of systems and data

Security around the standard organisational architecture is quite well understood, with acceptance that there are layers of security based on risk or impact levels, or around the value placed on particular assets – a key end result being separation: keep unauthorised individuals out, restrict an individual’s access to that which they need to do their job and host data of differing sensitivity on networks with different levels of protection.

Virtualisation can break this model – imagine your HR database and customer database virtualised onto the same environment as your web servers. All of a sudden the data which was once hidden behind layers of firewalls and network controls may be vulnerable to a smart attacker who gains access to the web server and finds an exploitable vulnerability in the virtualisation layer.

The same is true for servers hosted for customers – in the past, good practice kept these separate where possible. Now the segregation between different customers may be no more than between adjacent areas of memory or hard disk. This may not be appropriate for environments with differing risk, threat or impact ratings, for example external web servers and internal databases.

This also means that all servers or applications in the same environment should be secured to the same level, which means patch management becomes very important.

Segregation of duties

Consolidation of systems also introduces a risk of a loss of segregation of duties (SOD).  It increases the risk that both system administrators and users could potentially (and unintentionally) gain access to data that are above their normal privilege levels. Administration of the internal virtual switch is also a concern, thus introducing a conflict between server administrators and network administrators and therefore potentially compromising the SOD between the two groups.

Licensing and asset management

The ability to rapidly deploy new virtual infrastructure at short notice raises challenges around licensing. Virtualising applications and servers is often implemented by copying an instance of a server and this instance is recreated on the virtual host. When further capacity is required new instances are created, but as these can be very time dependent, the licensing model has to be updated to ensure that an organisation only runs applications they own a licence to (or that don’t require a licence in a virtual environment.)

This applies also to inventory – a virtual server is just as much of an asset to the business as a physical server, but with the number of virtual servers fluctuating with demand, how do you manage your assets appropriately?

Resilience

Although virtualisation can improve resiliency, there is also a risk if implementation is flawed.  If several key services are hosted within the same physical device in a single virtual environment then failure of the hardware device would impact several services simultaneously.

When consolidating servers, consideration should be given to distributing business critical applications with high availability requirements across physical server instances. There should be no single point of failure for a service and the use of anti-affinity rules should be considered to ensure resilient virtual machines within a service are kept on separate infrastructure hosts.

Maturity of tools and security awareness

While some virtual environments (such as the IBM LPAR architecture on mainframes) are considered mature, there is now a range of products in this space which have not been through the same level of development and which run on platforms less suited to multiple user segregation, and while there has been large scale development of PaaS platforms based on Xen, VMware and others, treating these as secure by default may not be appropriate for your business.

Another major risk around security awareness is that virtualisation is moving forward in some organisations without the knowledge or active participation of Information Security.

Administrators need to look at the particular security requirements prior to building a virtual environment in order to use the correct tools and security configuration to support the business requirements in an appropriate manner.

Information Security involvement is critical at these early planning and architecture decision stages.

Communication and Storage Security

Sensitive data being transmitted across networks should be encrypted where possible and supported by the hypervisor. Encryption should be implemented for traffic between the hypervisor, management networks and remote client sessions and MUST be for virtualised DMZ environments.

Virtual disks are used to store the operating system, applications and data and also record the state of the virtual machine. Virtual disks (including backed up copies) must be protected from unauthorised modification.

Where virtual disk password protection features exist, they should be enabled.

Restrict disk shrinking features which allow non-privileged users and processes to reclaim unused virtual disk space as this may cause denial of service to legitimate users and processes.

Auditing, logging and monitoring

Enable security logging and monitoring on all virtual machines and hypervisors according to approved operational standards.

Hypervisors must be configured, at a minimum to log (failed and successful) login attempts to management interfaces.

Activities of privileged hypervisor and VM accounts (for example, the creation, modification and deletion of roles) must be logged and reviewed.

Summary

• Understand all the key IT controls in the existing environment before virtualisation
• Understand virtual platform controls and configure for security
• Replicate IT controls in the virtualised environment
• Implement an asset management system which can cope with high volatility
• Work with software and hardware vendors to understand licensing implications
• If outsourcing to a cloud vendor, choose one that can match your data location requirements and build in a robust reporting framework
• Rearrange your support teams to suit the new environment, but during the transition it is likely that the learning curve will be steep as new tools are used, and back office and front office support teams are created anew
• Use a compliance and governance model which can manage the concepts of changing security boundaries and levels
• Ideally work with a service provider who has done it before!

The Question of the week this week was asked by nealmcb in response to the ever wider list of standards which apply in different industries. The Financial Services industry has a well defined set of standards including the Payment Card Industry Data Security Standard (PCI-DSS) which focuses specifically on credit card data and primary account numbers, but neal’s core question is this:

Are there standards and related server certifications that are more suitable for e.g. web sites that hold a variety of sensitive personal information that is not financial (e.g. social networking sites), or government or military sites, or sites that run private or public elections?

This question hasn’t inspired a large number of answers, which is surprising, as complying with security standards is becoming an ever more important part of running a business.

The answers which have been provided are useful, however, with links to standards provided by the following:

From Gabe:

• The Center for Internet Security (CIS)
• The National Institute of Standards and Technology (NIST)
• NSA

Of these, the CIS standards are being used more and more in industry as they provide a simple baseline which should be altered to fit circumstances but is a relatively good starting point out of the box.

Jeff Ferland provided a longer list:

• NIST standards
• FISMA
• COBIT
• ISO 27002
• Common Criteria
• ITIL
• COSO

And as I tend to be pretty heavily involved with the ISF, I included a link to the Standard of Good Practice which is publicly available and is exactly what it sounds like: rational good practice in security.

From all these (and many more) it can be seen that there is a wide range of standards which all have a different focus on security- which supports this.josh‘s comment:

As is often noted in questions and answers on this site, the solution depends on what you are protecting and who you are protecting it from. Even similar industries under different jurisdictions may need different protections. Thus I think it makes sense for specific industries and organizations to produce their own standards.

A quick look at questions tagged Compliance shows discussion on Data Protection Act, HIPAA, FDA, SEC guidelines, RBI and more.

If you are in charge of IT or Information Security, Audit or Risk, it is essential that you know which standards are appropriate to you, which ones are mandatory, which are optional, which may be required by a business partner etc., and to be honest it can be a bit of a minefield.

The good thing is – this is one of the areas where the Stack Exchange model works really well. If you ask the question “Is this setup PCI compliant” there are enough practitioners, QSA’s and experienced individuals on the site that an answer should be very straightforward. Of course, you would still need a QSA to accredit, but as a step towards understanding what you need to do, Security.StackExchange.com proves its worth.

Ian C posted this interesting question, which does come up regularly in conversation with people who don’t deal with security on a daily basis, and seems to be highlighted in the media for (probably) political reasons. The argument is “surely as long as you aren’t breaking the law, you shouldn’t need to prevent us having access – just to check, you understand”

This can be a very emotive subject, and it is one that has been used and abused by various incumbent authorities to impose intrusions on the liberty of citizens, but how can we argue the case against it in a way the average citizen can understand?

Here are some viewpoints already noted – what is your take on this topic?

M’vy made this point from the perspective of a business owner:

Tate Hansen‘s thought is to ask,

“Do you have anything valuable that you don’t want someone else to have?”

But the most popular answer by far was from Justice:

You buy a lock and lock your front door if you live in a city, in close proximity to hundreds of thousands of others. There is a reason for that. And it’s the same reason why you lock your Internet front door.

Iszi asked a very closely linked question “Why does one need a high level of privacy/anonymity for legal activities”, which also inspired a range of answers:

From Andrew Russell, these 4 thoughts go a long way to explaining the need for security and privacy:

If we don’t encrypt communication and lock systems then it would be like:

Sending letters with transparent envelopes. Living with transparent clothes, buildings and cars. Having a webcam for your bed and in your bathroom. Leaving unlocked cars, homes and bikes.

And finally, from the EFF’s privacy page:

Privacy rights are enshrined in our Constitution for a reason — a thriving democracy requires respect for individuals’ autonomy as well as anonymous speech and association. These rights must be balanced against legitimate concerns like law enforcement, but checks must be put in place to prevent abuse of government powers.

A lot of food for thought…

This week’s question, asked by @AviD, turned out to have subtle implications that even experienced security professionals may not have been aware of.

A quick bit of background:

With all the furore about passwords, most companies and individuals know they should have strong passwords in place, and many use system enforced password complexity rules (eg 8 characters, with at least 1 number and 1 special character) but how could a company actually audit password strength.

John the Ripper was a pretty good tool for this – it would brute force or use a dictionary attack on password hashes, and if it broke them quickly they were weak. If they lasted longer they were stronger (broadly speaking)

So far so good, but what if you are a security professional emulating an attacker to assess controls? You could run the brute forcer for a while, but this isn’t what an attacker will do – maths has provided much faster ways to get passwords:

Hash Tables and Rainbow Tables

Hash Tables are exactly as the name sounds – tables of hashes generated from every possible password in the space you want, for example a table of all DES crypt hashes for unsalted alphanumeric passwords 8 characters or less, along with the password. If you manage to get hold of the password hashes from the target you simply match them with the hashes in this table, and if the passwords are in the table you win – the password is there (excluding the relatively small possibility of hash collisions – which for most security purposes is irrelevant as you can still use the wrong password if its hash matches the correct one). The main problem with Hash tables is that they get very big very quickly, which means you need a lot of storage space, and an efficient table lookup over this space.

Which is where Rainbow Tables come in. @Crunge‘s answer provides excellent detail in relatively simple language to describe the combination of hashing function, reduction function and the mechanism by which chains of these can lead to an efficient way to search for passwords that are longer or more complex than those that lend themselves well to a hash table.

In fact @Crunge’s conclusion is:

Hash tables are good for common passwords, Rainbow Tables are good for tough passwords. The best approach would be to recover as many passwords as possible using hash tables and/or conventional cracking with a dictionary of the top N passwords. For those that remain, use Rainbow Tables.

@Mark Davidson points us in the direction of resources. You can either generate the rainbow tables yourself using an application like RainbowCrack or you can download them from sources like The Shmoo Group, Free Rainbow Tables project website, Ophcrackproject and many other places depending on what type of hashes you need tables for.

Now from a defence perspective, what do you need to know? 

Two things:

Longer passwords are still stronger against attack, but be aware that if they are too long then users may not be able to remember them. (Correct Horse Battery Staple!)

Salt and Pepper. @Rory McCune describes salt and pepper in this answer:

A simple and effective defence that most password hashing functions provide now is salting – the addition of a per user “salt” value stored in the database along with the hashed password. It isn’t intended to be secret but is used to slow down the brute force process and to make rainbow tables impractical to use.  Another add-on is what is called a “pepper” value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database.

A key aspect of IT and Information Security is the acceptance piece. People aren’t naturally good at this kind of security and generally see it as an annoyance and something they would rather not have to deal with.

Because of this, it is typical in organisations to send out regular security update emails – to help remind users of risks, threats, activities etc.

However it is often the case that these are deleted without even being read. This week’s question: How to write an email regarding IT Security that will be read, and not ignored by the end user? was asked by @makerofthings and generated quite a number of interesting responses, including:

• Provide a one line summary first, followed by a longer explanation for those who need it
• Provide a series of options to answer – those who fail to answer at all can be chased
• Tie in reading and responding to disciplinary procedures – a little bit confrontational here, but can work for items such as mandatory annual updates (I know various organisations do this for Money Laundering awareness etc)
• Using colours – either for the severity of the notice, or to indicate required action by the user
• Vary the communications method – email, corporate website, meeting invite etc
• Don’t send daily update messages – only send important, actionable notices
• Choose whose mailbox should send these messages – if it is critical everyone reads it, perhaps it should come from the FD or CEO, or the individual’s line manager
• Be personal, where relevant – users who receive a few hundred emails a day will happily filter or delete boring ones, or those too full of corporate-speak. Impress upon users how it is relevant to them
• Add “Action Required” in the subject

It is generally agreed that if it isn’t interesting it will be deleted. If there are too many ‘security’ emails, they’ll get deleted. In general, unless you can grab the audience’s attention, the message will fail.

Having said that, another take on it is – do you need to send all these security emails to your users? For example, should they be getting antivirus updates or patch downtime info in an email every week?

Can users do anything about antivirus, or should that be entirely the responsibility of IT or Ops? And wouldn’t  a fixed patch downtime each week that is listed on the internal website make less of an impact on users?

Thinking around the common weak points in security – such as users – for most actions can make much more impact when you actually do need the users to carry out an action.

Associated questions and answers you should probably read:

What are good ways to educate about IT Security in a company?

What policies maximize employee buy-in to security?

This week’s post came from this question: I just discovered major security flaws in my web store!, but covers a wider scope and includes some resources on Security Stack Exchange on defending your website.

Any application you connect to the Internet will be attacked within minutes of plugging it in, so you need to look very carefully at protecting it appropriately. Guess what – many application owners and developers go about this in entirely the wrong way, building the application and then thinking about security at the very end, where it is expensive and difficult to do well.

The recommended approach is to build security in from the start – have a look at this post for a discussion on Secure Development Lifecycle. This means having security as a core pre-requisite, just like performance and functionality, and understanding the risks your new application will bring. Read How do you compare risks from your websites, physical perimeter, staff etc

To do this you will need developers to write the application securely. Studies show that this is the most cost effective in the long run, as securely developed applications require very little remediation work (as they don’t suffer from anywhere near as many security flaws as traditionally developed applications)

So, educating developers is key – even basic awareness can make the difference: What security resources should a white-hat developer follow these days?

Assuming your application has been developed using secure practices and you are ready to go live, What are the most important security checks for new web applications? and Testing your web application to gain some confidence that the security controls you have implemented are correctly working and effective is an essential step before allowing connection to the Internet. Penetration testing and associated security assessments are essential checks.

What tools are available to assess the security of a web application?

The globally recognised open standard on web application security is the Open Web Application Security Project, (OWASP) who provide guidance on testing, sample vulnerable applications, and a list of the top ten vulnerabilities. The answers to Is there a typical step-by-step A-Z process for testing a Web site for possible exploits? provide more information on approaches, as do the answers to Books about Penetration Testing.

Once your application is live, you can’t just sit back and relax, as new attacks are developed all the time – being aware of what is being attempted is important.  Can I detect web app attacks by viewing my Apache log file is Apache specific, but the answers are broadly relevant for all web servers.

This is obviously a very quick run-through – but reading the linked questions, and following the related questions links on them will give you a lot of background on this topic.

Despite the security industry getting ever more professional, with well trained teams, security incidents seem to be increasing. Just look at the news recently:

• Sony – 23 incidents so far?
• UK NHS Laptop – over 8 million patient records
• Citibank – 200,000 customer records lost
• WordPress platform vulnerabilities (see Steve Lord’s presentations on this)
• Stuxnet – targeted at a specific use

From the 2011 Verizon DBIR

• 761 breaches of which 87% were in Hospitality, Retail and Financial Services
• 436 of these were in companies with 11-100 employees – so this is not just a problem for the big targets any more
• 92% of attacks (leading to 99% of records compromised) were external

Some new threat groups:

Anonymous and LulzSec – often punitive, sometimes for the Lulz

• HBGary
• ACS Law
• Spanish Police
• FBI, CIA
• Porn sites
• Took requests

So what do the security professionals do?

• After an audit fix vulnerabilities
• After an attack, fix the issues
• Use encryption and strong authentication
• Patch regularly
• Validate input, encode output
• Assess your 3rd parties
• Use a Secure Development Lifecycle
• Build security into everything you do

No problem, right?  If only it were that easy…

Your CEO wants the business to make money, so wants to minimise bottom line spend but will spend appropriately on risks to the business.

So why doesn’t the CEO see these security issues as business risks?

• Maybe they aren’t significant when compared to other business risks
• Or perhaps the CEO just doesn’t understand the latest security threat

Both of these are your problems. The security community is often called the ‘echo chamber’ for a good reason – we say good things and have good ideas about how to fix security issues, but we pretty much only communicate with other enlightened security professionals. We need to tell others in a way they can understand – but in general we talk technical 1337 speak full of jargon and no one can make head or tail of it.

It is up to you, the security professional to learn how to talk the language of business risk

There are materials out there that will help you:

• IIA GAIT – Guide to the Assessment of IT Risk
• FAIR – Factor Analysis of Information Risk
• ISACA CobIT – Control Objectives in IT
• ISACA – CRISC and CGEIT certifications
• IISP – approved Information Risk Management courses

Begin to understand what is important to a business executive and how they talk about it, and you are already well on the way to being able to articulate security in the same way. If you are a manager of security professionals, make it easy for them to gain exposure to heads of business, C-suite, executive, directors etc. and it is likely to benefit you in the long run.

These are good questions to prepare you for conversations you may have along the way

• What metrics should a CIO rely on to gauge risk
• How would you work with the security paranoiac on your team
• Can you provide loss values on security breaches
• How do you compare risks from website, physical perimeter, staff, etc.
• What are good threats to kick off conversations with others about what worries them