Thursday, 25 November 2010

When was the last time you read an EULA?

Most if not all of us will by default approve the end user licence agreement and never give it another thought. I am the same, however the other day I happened to download a dictation app for the iPhone and decided to read through the EULA and here are my findings:


As part of the service the provider can;



  • "collect and use the contact names that appear in your address book"


  • "You allow (company name) to do so by enabling the Service."

It is then your responsibility to know they have done this and to update the software settings to prohibit this access. Once done the provider will;



  • "delete all contact names that it has collected from your address book."

The first question has to be why do they need my contacts? Secondly, why is this an opt out process that attempts to close the barn door after the horse has bolted?

On the positive side;



  • "will not use the data you provide to contact any of the contact names that appear in your address book for any reason, nor will (company name) share contact names you provide with any third party."

Oh, that's ok then, nothing to worry about, but wait! Within the EULA is a URL link to a further page that states -



  • "(company name) would like its software to send speech data to (company name) to improve the accuracy of this and future products or services. We do this because our software and other offerings can learn from experience about the language you use. “Speech Data” means the audio files, associated transcriptions and log files provided by you hereunder or generated in connection with the product or service. By clicking the “ACCEPT” button when installing the software, you agree to the collection and processing of such Speech Data as set out in this privacy policy."

Ok, so now they have my contacts and take copies of my audio files to keep? I hope I never say anything bad about one of those people in my phone book! So who has access to this information?



  • "The only people with access to this data will be our employees, research partners, permitted agents, sub-contractors etc. on a need to know basis, all of whom are bound by obligations of confidentiality to keep the data strictly confidential."


Oh ok, everyone then, and where will this data reside?



  • "will transfer the personal data to its data collection sites. These may be located outside of the European Economic Area (EEA). However, (company name) shall ensure that any such transfer is compliant with the European Union Data Protection Directive."

So the transfer of data will be compliant with the EUDPD, how about the processing and storage of this data? Not to mention the lack of any discussion around information security for the data collection sites.


In summary, I have no reason to presume that this organisation has any intention to treat my personal data in a malicious or evil manner or that they are doing anything wrong / unethical. The reason for the blog is to highlight that we shouldn't blindly trust organisations and that we should be more aware of the contractual rights you are placing when accepting EULAs.


To that end I made a personal decision to not click 'accept' and I removed the app from the iPhone.


Back to old school note taking.

Wednesday, 17 November 2010

Security in Scotland

A topic very dear to the 7 Elements team is the development of the Information Security profession, but specifically in Scotland, and we thought it would be worthwhile posting some information on initiatives in Scotland that help with this aim, as well as discuss areas where stronger involvement from the wider industry would be welcomed. We have selected a few of the key organisations and events, but if you feel we another is key, please let us know and we'll update this post.

The Institute of Information Security Professionals, of which Rory Alsop is the Scottish chair, is providing support and guidance to universities and companies across the UK through the Graduate Development Scheme, Academic Partnerships, the Accredited Training Scheme and the IISP Skills Framework. The IISP's mission is to be the authoritative body for information security professionals, with the principal objective to advance the professionalism of the industry as a whole. Whilst the existing IISP membership in Scotland is strong I would encourage individuals and companies to visit the website or speak to representatives to understand what they can get out of membership (at all levels from student through to full membership) and more importantly for the industry what they can offer in return from their own experience or skills. The IISP always welcomes speakers who have a story to tell in the information security space, so please get in touch if you would like to present at one of our quarterly events.

Similarly, ISACA aims to define the roles of information systems governance, security, audit and assurance professionals. Through close links with local industry, ISACA Scotland provides guidance, benchmarks and effective tools for organisations in Scotland. The majority of members in Scotland have the CISA certification so here there is a very strong focus on audit and control, but we are seeing increasing numbers in security management, governance of enterprise IT and risk and information systems control. Like the IISP, ISACA Scotland would welcome guest presenters or new members - the global knowledge base and information flow are extensive and the opportunities for networking are invaluable.

The Scottish Universities, under the leadership of Professor Buchanan have created the framework for a Centre of Excellence in Security and Cybercrime in Scotland - with strong links already forming between academia, law enforcement, industry and professional bodies such as the IISP. One goal is to provide academia with a greater awareness of real world security issues and activities through a number of avenues including volunteer work, summer placements, guest lecturers etc. From the perspective of your organisation, if you find that when hiring software developers, for example, you need to give them additional training in secure development or spend resource remediating vulnerable code, the argument for providing a small amount of resource to help develop coursework in these subjects, or to provide the odd guest lecture is a very strong one. 7 Elements are strongly bought into the concept that as an industry we can make great improvements by simply providing the new entrants with the benefits of at least some of our years learning the hard way.

The e-Crime Scotland website was officially launched at the Scottish Financial Crime Group Conference on the 28th of October. Currently this has been set up with support from, and using the framework developed by the Welsh Assembly, demonstrating an excellent level of sharing of expertise and resource. This website provides a portal of information on e-crime, a reporting mechanism and is planned to develop as Scotland takes greater ownership of content.

The Scottish Financial Crime Group, under the ownership of the Scottish Business Crime Centre, has been working with law enforcement and clearing banks for the last 35 years, but more recently through the annual conferences and an active presence in many forums has been in a good position to draw on expertise from a wide range of specialist individuals and organisations to develop opportunities to disrupt the criminal element in our society. Membership of the SFCG or at the very least, attendance at the annual conference is invaluable both from a learning perspective and an opportunity to influence discussion relating to financial crime.

The National Information Security Conference is held in St. Andrews each summer and provides speakers renowned within their field, education and an excellent networking opportunity to meet like minded individuals from industry and security experts. This three day residential event attracts many security professionals who are trying to drive the industry forwards and should not be missed!

On the more technical front, the Scottish OWASP chapter, headed up by Rory McCune is a growing group of individuals from across various industries focused on improving web application security. Join the mailing list to find out about meetings, initiatives etc. The scope of interest includes everything from SCADA to online banking and from smart meters to social networking.

Monday, 8 November 2010

Key Security Risks and Practical Remediation - ISACA Event notes - October 26 2010

Rory Alsop, Vice-President of ISACA Scotland and chairman of the Scottish branch of the IISP chaired a session titled "Key Security Risks and Practical Remediation." Audit Scotland hosted the session, and we had a good turnout representing the financial and government sectors as well as law firms and retail.

A quick introduction from round the table did confirm that the problems faced were common - low resource or budget, escalating security and risk requirements, ever increasing threats, targets spreading - not just large financial organisations any more, so the opportunity to outline some simple, effective activities which any organisation could carry out was highly appropriate.

For our regular readers, some or all of the following should be old news, however we still see so few organisations carrying out basic remediation activities that we would recommend reading and looking to see where you can improve the security in your environment through these simple steps. The risk areas were taken from OWASP, Verizon and WHID work to identify the most common issues.

We would stress that nothing here is a magic bullet to cure all ills, but if you can take some of the actions listed you will be improving your security baseline without incurring too high a cost:

Input Validation

Very old news, but:
  • The top two web application security risks (OWASP top 10 list) are Injection and Cross Site Scripting, both of which can be successfully mitigated by strong input validation
  • The 2010 Data Breach Report by Verizon lists the top two causes of breaches as use of Stolen Credentials and SQL Injection
  • Examples include Worldpay from 2008 (over $9.4Million stolen) and the Royal Navy this week - this is still an issue
This is a relatively easy area to improve on:
  • Popular frameworks have input validation modules – why not use them
  • With modern applications, a call to an input validation module is often straightforward
  • Never trust the client – validate all input at server side
  • White listing or black listing - both are acceptable and have their own pros and cons
Also think about output encoding – providing strongly validated output will also help prevent SQL Injection and Cross Site Scripting attacks, although it typically requires more effort to accomplish.

Brute Force and Dictionary attacks

More old news, but:
  • The 2010 WHID Report by the Web Application Security Consortium lists Brute Force attacks in the top 5
  • Tools to carry out brute force or dictionary attacks are simple to use, prevalent and free
  • Humans are still pretty bad at choosing strong passwords

Remediation should be in a number of areas:
  • Brute forcing shows up in logs – typically it generates a high network load and can usually be spotted by simple statistical analysis tools
  • Utilise exponential delays - eg 5 seconds after 1 failed attempt, 10 after the second, 30 after the third etc. This rapidly makes brute forcing unusable, without requiring account lockouts (which often require helpdesk resource)
  • Awareness training works – for a few months at a time. Combined with regular password strength audits this can have lasting effect
Prevalence of 0-day exploits

For organisations with significant assets that are targeted by organised crime (FS, Government, Pharmaceuticals etc.) there's an increasing likelihood that 0-days will be part of the attack. This throws an interesting light on defensive controls other than patching and configuration, as you can only patch for weaknesses you know about.

Use of IDS/Log monitoring becomes more important - you won’t necessarily catch the initial attack (no signature available) but you may be able to catch the attacker doing things afterwards. At the very least detective controls can help the incident response and clean up.

Defence in depth – another old mantra, but it helps. While a 0-day can get an attacker through a security device, or an application control, multiple layers require more work, or a longer time frame – during which time the issues may be patched.

Client-side Attacks

Krebs reported on the increasing wave of attacks targeting Java (not javascript) on client PCs. It's a common mistake for client patching not to touch Java (especially as some applications require specific older versions).

Microsoft and Qualys have both confirmed the scale of the issue with over 40% of all PC’s being vulnerable, and over 90% of all successful exploits in the Blackhole toolkit and over 50% of those in the SEO Sploit Pack being through Java. The Crimepack and Eleonore exploit packs also show Java flaws to be the leading exploit vectors.

The simple answer is to remove Java from machines. Most do not need it!

For those that do need it, keep it up to date. Very few developers update their code with the latest revisions, which can hinder user uptake of the latest Java update, so ensure your developers are kept up to date.

As part of audit look at the budget assigned for product maintenance or ongoing development

The Cloud

Moving to ‘The Cloud’ is popular – it can save money on hardware costs, it is flexible, it can save power and is generally considered a good thing™ for business.

  • Unfortunately it tends to break security structures, as layers which used to be in different environments, such as DMZs, may now be on the same physical platform, and may no longer have firewalls or other access control devices present
  • The volatile and dynamic nature of virtual environments can mean asset registers and licensing are difficult to manage
  • The tasks which used to be separated out to network, system, database and platform administrators may now be carried out by one team
Good practice includes the following steps:

  • Model the new architecture on existing good practice
  • Be aware of the requirements of a highly volatile asset register, and licensing requirements for dynamic assets
  • Understand segregation of duties needs between administrators

Widespread DDoS

WHID and Verizon indicate a dramatic increase in Distributed Denial of Service attacks:

  • Blackmail, especially of internet gambling sites is on the increase
  • Punishment DDoS (for example ACS Law) removing web sites from the internet in response to an action
  • Bot net slots available for hire at cheap rates
(update - the DDoS against Burma last week shows the traffic levels which can be generated: at 10-15 Gbps this was significantly larger than the 2007 Georgia attack at 814 Mbps)

It is very difficult to resist a Distributed Denial of Service attack – even a small bot net can overwhelm a company’s Internet connection
Concentrate instead on resilience – do you have a fully tested business continuity plan or IT disaster recovery plan which can cope?
Does your ISP have mechanisms to mitigate such an attack?

IPv4 Address Space Exhaustion

Little bit more off the wall –

Whilst some of the stories around at the moment are probably more scare mongering than anything else, it seems likely that 2011 is going to see a greater restriction in IPv4 address and subsequently a big push to IPv6.

The interesting part is that a lot of security controls are dependent on IPv4 ways of thinking and there's also a big risk that new IPv6 implementations will require different ways of implementing network security and will be buggy early on.
  • Review your networks to understand the security structures in the infrastructure and protocol stacks
  • Work with your telecommunications and network service providers to ensure you are prepared
More Generally

I would remind auditors that they need to not only ensure that each security management process is in place but that it works works.
A modicum of technical assurance work (vulnerability analysis by an experienced person) will go a long way.

Work in partnership with IS specialists to:
  • Add value to audits and gain a more holistic picture of the current state of security
  • Understand new threats and risks
  • Always take a holistic look – what are the threats to the business, not just to IT
  • Improve your security testing process – we have demonstrated over 30% savings through managing security testing and assessment efficiently
Threats will continue to develop – aim for resilience!

References

OWASP Top Ten
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Verizon Data Breach Report
http://www.verizonbusiness.com/resources/reports/rp_2010-data-breach-report_en_xg.pdf

Krebs Java Security Report
http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/

WHID Security Report
https://files.pbworks.com/download/loBVUfSYDp/webappsec/29750234/WHIDWhitePaper_WASC.pdf

Potaroo IPv4 Address Report
http://www.potaroo.net/tools/ipv4/index.html

Tuesday, 2 November 2010

IISP event on 4th November 2010

The next Scottish branch of the Institute of Information Security Professionals event is on the 4th of November, and will be kindly hosted by Napier University in Edinburgh (room F.29 at the Merchiston campus). Come along if you are in Scotland and:
  • a member of the IISP
  • in the Information Security industry and thinking of joining the IISP but wondering what membership can give you
  • studying computer science, software development or associated undergraduate courses and want to know more about the industry
  • or just want to network with like minded security professionals
Rory Alsop, the chair of the Scottish branch, is delighted to welcome two speakers:
  • IISP Member - Matthew Pemble: "Preparing for the End - Data Destruction". Matthew is a popular speaker at many conferences and events and from two aspects of his day job has a pretty interesting take on this topic. Find out more at Idrach's website.
  • IISP Programmes Manager and Chief Operations Officer - Triona Tierney: "The IISP Graduate Development and University Outreach Programmes" - if seriously considering information security as a career this talk could be invaluable.

Kickoff is from 6 for 6.30. Please do come along and support your local branch, join in the lively discussion, and meet fellow IISP members in your area. For more information and to register for this meeting, please email events@instisp.com

The best source for joining instructions/maps etc is the Napier Merchiston page - it includes a link to Google Maps.

CYA (Consider Your Audience)

Just picking up on one of the points from the discussion Rory Alsop and Chris Riley were having on the penetration testing industry. I've been giving some thought to the issue of communication.

With any presentation or document, probably the most important thing to think about is "who will be receiving this information"? Definitely whenever I'm preparing a presentation, that's the first thing I think about, as it drives the rest of what I create.

Now in the penetration testing industry the main means of communication is the post-test report. Whether that's purely a written document that's handed over at the end of testing, or handled as part of a wash-up meeting, it's the tester's main opportunity to communicate what they did and what the real value of the test was.

Unfortunately in a lot of cases, the opportunity to customize the report heavily for a specific audience isn't available, as it'll go to multiple groups, but with a wash-up meeting there can be some good opportunities to focus on the test in different ways.

To illustrate the point, lets take a pretend test for Hypothetical Corp, which looked at their perimeter network and their main transactional web application.

Lets say there were findings for unencrypted management protocols on external devices, out of date web server software and several web application findings, in session management, authorisation and input validation (SQL Injection and XSS), the standard type of things you may see in many areas.

Now we've been asked to do a wash-up meeting to explain our findings. Depending on who the main people at the meeting are, I'd say there's at least three completely separate ways to present this information.

If we're presenting to developers and admins, you could focus on:
  • Exactly which areas of the application had input validation issues, what the best way of mitigating those is, possible ways that their app. framework could be used to help them.
  • For the unencrypted management protocols, you might talk about sensible alternatives that still allow the admins to get access (VPN, move to encrypted protocols, partial mitigation like source IP address restrictions etc.)
  • Demonstrate authorisation problems in the application and explain how an attacker might be able to get additional access to the system. Again suggesting how you'd recommend that they approach fixing it can be very useful.
If we're presenting to the IT Security team you could take a slightly different tack:

  • Talking about potential for an attacker to use the issues discovered (eg, SQL injection) to expand their attack and compromise additional areas of the environment.
  • Talk about current trends in attacks, providing some information on attacks that are likely.
  • Look at what data is potentially compromised by any of the attacks, particularly in terms of any credit card or personal information that may have a regulatory impact if it's lost.
Lastly, you may be "lucky" enough to present your findings to senior management, and again there's probably a different set of things that they're interested in:

  • Potential business impacts of one of the findings being exploited. Loss of customer data, regulatory fines etc.
  • Where the organisation is, in comparison to other companies in their industry or area, is likely to be of interest.
  • Demos (if possible). My experience has been that actually demonstrating how easy a compromise is can be quite convincing to senior management.
So here we see three different presentations, all from the same test, and there are numerous other ways that this information could be tailored, depending on the audience.

The main point of all this, is that considering the recipient of any information is key to getting your message across.

Building in time to understand the potential audience at the start of the engagement can be invaluable. For more mature buyers of security testing, agreeing standard formats or documents which have standard sections which can be pulled out as needed can help to get the message across effectively, e.g. a report with a targeted executive summary, plus an xml section for the techies so they can grab the data into their own reporting tool.

One further point which we have seen on occasion is where a test offers findings which are the responsibility of different 3rd parties. Delivering a single report back may not be allowed as confidentiality could be breached. What we have had to do in these situations is write up multiple reports for the same level of audience, but with sections redacted. Planning for this at the start of a test will save you time.