25 February 2014

Policies

Posts relating to the category tag "policies" are listed below.

30 March 2012

Application Security Gap Study

A new report from Ponemon Institute describes the results from a survey of developers and information security employees in the United States.

Key finding: Application security is often not a priority

2012 Application Security Gap Study: A Survey of IT Security & Developers provides useful data on the viewpoints from these important groups, and of course isn't necessarily encouraging reading. A very small proportion of the IT security budget is spent on application security, most do not have a standardised way of building security into new applications and security is most often addressed in later stages of the software development life cycle (SDLC). See the overview on the ISACA website.

The information could be used to help compare secure software development life cycle (S-SDLC) maturity, but the input of other groups such as product owners, architects, testers, QA, audit and operations would also provide useful data, and hopefully senior management might be able to provide an oversight of the all the processes and the organisation's needs and risk profile.

Posted on: 30 March 2012 at 09:20 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

21 February 2012

Data Protection Framework Call for Evidence

In response to last month's proposals for reform to data protection legislation by the European Commission, the UK's Ministry of Justice has announced a call for evidence on the proposals.

Photograph of Karla Black's Turner Prize 2011 Installation at the Baltic in Gateshead

The call for evidence is seeking information from data controllers, data processors, rights groups, information policy experts and others on what might be the impacts and benefits of the potential changes. The aim is to provide the Government with information it can use during the forthcoming negotiations relating to the proposed framework.

Let's hope this helps to develop a practical, workable framework. Whatever the outcomes, building privacy concerns into systems and processes from the start will reduce the subsequent administrative burden. Have your say now — rather than when it is too late. Responses can be submitted by post, email and using the online form to answer the questions:

  • How will the proposals affect you, or the bodies you represent?
  • Wherever possible we would like quantifiable costs and benefits and real-life examples of the potential impact of the proposals.

The call for evidence closes on 6th March 2012.

Posted on: 21 February 2012 at 08:01 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

05 February 2012

BITS Software Assurance Framework

BITS, the technology policy division of the Financial Services Roundtable, an industry body representing the US financial services industry, has published a Software Assurance Framework.

The 50-page guidance document describes an outline of recommended components of what they describe as a "mature, strategic program for secure software development" for software used within the US financial services industry. The framework was a collaborative effort that involved several financial services companies in conjunction with Microsoft, and it references the Microsoft-sponsored Forrester Consulting research which indicated that the use of a prescriptive secure software development lifecycle achieves the greatest return on investment (see also the similar Aberdeen Group research).

This is not a hands-on "how to" for software architects, developers, testers or operational staff, but instead describes a framework of activities that contribute to the specification, production, deployment and operation of secure software throughout the development lifecycle. In that respect, the comparable documents to refer to are BSIMM, MS SDL and Open SAMM, and indeed these are referenced in the BITS framework. Some organisations also build their software assurance efforts around the Capability Maturity Model Integration (CMMI).

So what does BITS consider to be the key components of a software assurance framework? Eight are defined and explained:

  • Education & Training
  • Security Software Assurance Development Standard
  • Threat Modeling
  • Coding Practices
  • Security Testing
  • Pre-Implementation Practices
  • Software Assurance Documentation Archive Best Practices
  • Post-Implementation Phase Controls

There is of course considerable overlap with the references mentioned above which describe actual practices in place, how Microsoft undertakes secure SDLC and a maturity model for software assurance respectively. I have tried to indicate below how the BITS key components broadly map to Open SAMM:

BITS Component SAMM v1.0 Business Function: Security Practice
Education & Training Governance: Education & Guidance
Security Software Assurance Development Standard Governance: Strategy & Metrics
Governance: Policy & Compliance
Construction: Security Requirements
Construction: Secure Architecture
Threat Modeling Construction: Threat Assessment
Coding Practices Governance: Policy & Compliance
Governance: Education & Guidance
Security Testing Verification: Design Review
Verification: Code Review
Verification: Security Testing
Pre-Implementation Practices Deployment: Operational Enablement
Software Assurance Documentation Archive Best Practices (Through all above security practices)
Post-Implementation Phase Controls Deployment: Vulnerability Management
Deployment: Environmental Hardening
Deployment: Operational Enablement

So quite a lot of overlap. There is an existing mapping of Open SAMM to BSIMM activities which could be used to extend the above mapping onto BSIMM. As the BITS framework has been developed in conjunction with Microsoft, I expected to see a much closer relationship with MS SDL, and yes this is the case.

BITS Component MS SDL v5.1 Phase: Process
Education & Training Training: Core Security Training
Security Software Assurance Development Standard Requirements: Establish Security Requirements
Requirements: Create Quality gates/Bug Bars
Requirements: Security & Privacy Risk Assessment
Design: Establish Design Requirements
Threat Modeling Design: Analyze Attack Surface
Design: Threat Modelling
Coding Practices Implementation: Use Approved Tools
Implementation: Deprecate Unsafe Functions
Security Testing Implementation: Static Analysis
Verification: Dynamic Analysis
Verification: Fuzz Testing
Verification: Attack Surface Review
Pre-Implementation Practices Release: Incident Response Plan
Release: Final Security Review
Software Assurance Documentation Archive Best Practices Release: Release Archive
Post-Implementation Phase Controls Response: Execute Incident Response Plan

There isn't a direct one-to-one mapping here, but I hope the above help navigate the document if you use Open SAMM or MS SDL and want to delve into another source of ideas for secure software development lifecycles. Although the BITS framework might be somewhat heavyweight for some non-financial services organisations, especially on the documentation front, it is perhaps an easier starting point than the closely related MS SDL, to begin working on building security into development (and acquisition) processes. Take what suits, makes sense and fits your own organisation's type of applications and tolerance of risk.

Most of the content will be relevant, and since it is spelt out in reasonable detail, this could be very helpful. Some notable nuggets deeper in the document are:

  • pp2-3 "teaching techniques of good design and their subsequent use can result in software secure not just against known attacks, but also against unknown attacks and attacks yet to come"
  • p20 "Security defects are "defects", not just "security defects"
  • p35 Security vulnerabilities identified in applications in production .... should not be treated as software defects, but as one part of the company's incident response process".

And on page 36 in the section relating to emerging threats in the post-implementation phase controls, there is a comment relating to the OWASP Top Ten and CWE/SANS Top 25 which seems out of kilter with the rest of the framework's text. The document states these as being valuable sources of information but "both represent an earlier generation of software security intelligence". I am not sure each of those sources set out to define the only threats to consider, and are instead a way of introducing the concepts to less-knowledgeable groups and encourage reading of the much deeper related materials. But perhaps this is more of a comment about PCIDDSS which specifically mentions these two sources. I wonder.

As you can see, worth the read.

Posted on: 05 February 2012 at 20:56 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

27 January 2012

Happy Data Privacy Day Eve!

Yes, had you forgotten it's Data Privacy Day tomorrow? See StaySafeOnline for events in the US and Canada. Not sure why it's a Saturday — maybe to give the weekend journalists a story they can prepare in advance, and then take the day off.

While there is a programme of events, data protection has been in the news this week following the publication on Wednesday of the European Union's proposed reform of data protection legislation, promoted under the banner of aiming:

to increase users' control of their data and to cut costs for businesses

There has been extensive documentation and justifications published to accompany the draft directive. There is of course plenty of coverage elsewhere, and I would recommend reading the following:

So, what does it mean? For now, these are just proposals, and what will eventually be made into law will be something very different. But it does indicate the way things are going, and is a reminder to website and application owners & developers of the need to take privacy considerations into their projects now, since the cost of changes later may be prohibitive. And, they should be doing this already, but there may be more obligations for those processing personal data in the future. There is potentially more complex functionality required for tracking consent, achieving data portability, handling withdrawal of consent and undertaking data removal.

And, there is the topic of mandatory notification of "serious" breaches.

Data Privacy Day might be a day of reading after all.

Posted on: 27 January 2012 at 07:46 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

20 December 2011

Security Breach Guidance for European Telecommunications Operators

Last week, the European Network and Information Security Agency (ENISA) announced the publication of two guidance documents relating to Article 13a of the new telecommunications legislation (Directive 2009/140/EC) regarding security incidents and security controls.

Article 13a
Security and integrity
1. Member States shall ensure that undertakings provid­ing public communications networks or publicly available electronic communications services take appropriate techni­cal and organisational measures to appropriately manage the risks posed to security of networks and services. Having regard to the state of the art, these measures shall ensure a level of security appropriate to the risk presented. In particu­lar, measures shall be taken to prevent and minimise the impact of security incidents on users and interconnected networks.
2. Member States shall ensure that undertakings provid­ing public communications networks take all appropriate steps to guarantee the integrity of their networks, and thus ensure the continuity of supply of services provided over those networks.
3. Member States shall ensure that undertakings provid­ing public communications networks or publicly available electronic communications services notify the competent national regulatory authority of a breach of security or loss of integrity that has had a significant impact on the opera­tion of networks or services.
Where appropriate, the national regulatory authority con­cerned shall inform the national regulatory authorities in other Member States and the European Network and Infor­mation Security Agency (ENISA). The national regulatory authority concerned may inform the public or require the undertakings to do so, where it determines that disclosure of the breach is in the public interest.
Once a year, the national regulatory authority concerned shall submit a summary report to the Commission and ENISA on the notifications received and the action taken in accordance with this paragraph.
4. The Commission, taking the utmost account of the opinion of ENISA, may adopt appropriate technical imple­menting measures with a view to harmonising the measures referred to in paragraphs  1, 2, and  3, including measures defining the circumstances, format and procedures applicable to notification requirements. These technical implementing measures shall be based on European and international stan­dards to the greatest extent possible, and shall not prevent Member States from adopting additional requirements in order to pursue the objectives set out in paragraphs 1 and 2.
These implementing measures, designed to amend nonessential elements of this Directive by supplementing it, shall be adopted in accordance with the regulatory procedure with scrutiny referred to in Article 22(3).

I don't often quote legislation here, but I thought it was relatively short and provides the intent behind ENISA's guidance. ENISA has published two documents.

Technical Guideline on Incident Reporting provides guidance on the annual summary of significant issues and the notification of cross-border incidents. While most (all?) readers of this blog won't necessarily work in the telecommunications sector, I think the document is useful more widely for two aspects. It demonstrates the type of reporting which could be required if breach notification becomes a requirement for other sector or types of data (e.g. personal data)in the future. Also, the Section 5 on impact parameters and thresholds provides some insight into the continental and national viewpoint on the effects of security incidents.

The second document Technical Guideline on Minimum Security Measures defines the security controls national regulators need to consider when evaluating public communications networks. These are relatively high-level and are grouped into governance/risk management, human resources security, security of systems and facilities, operations management, incident management, business continuity management, and monitoring, auditing and testing. So a clear mapping to ISO27001/2/5 for information security and risk management, and BS 25999 for business continuity.

Posted on: 20 December 2011 at 06:47 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

13 December 2011

Updated and Improved Guidance on Use of Cookies, Etc.

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

Cover from the ICO's updated 'Guidance on the Rules on use of Cookies and Similar Technologies'

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

Posted on: 13 December 2011 at 15:21 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

02 December 2011

UK Cyber Security Hub

Last week the UK government's Cabinet Office published its new cyber security strategy.

Sections form the UK's 'Cyber Security Strategy 2011 - Protecting and promoting the UK in a digital world' discussing the cyber security hub

The Cyber Security Strategy describes the government's commitment to this "tier 1" risk. In the objective to make the UK "more resilient to cyber attacks and better able to protect our interests in cyber space", I hope the "risk-based approach..." "...working in partnership" which includes "raising business awareness" includes helping organisations of all sorts acquire and develop software which is secure and fit-for-purpose.

In particular, I hope the Cyber Security Hub will be able to promote secure software development lifecycles.

Posted on: 02 December 2011 at 00:52 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

15 November 2011

Cross-Site Tracking Preference using Do Not Track

The W3C's Tracking protection Working Group has published two working draft proposals for implementing "Do Not Track" online.

Part of the W3C's W3C Working Draft 14 November 2011 on 'Tracking Preference Expression (DNT)'

The proposals will allow users to define whether or not data about them can be collected for tracking purposes. Thus the proposals include information on how consumers express their tracking preference, and also how the websites and related systems (e.g. affiliates) will acknowledge those preferences.

Tracking Preference Expression (DNT) (W3C Working Draft 14 November 2011) describes how users express their preference and how websites indicate whether they honour such preferences. The proposal is to utilise a new HTTP request header "DNT", a machine-readable web-accessible file defining the site's tracking policy and an HTTP response header for the site to communicate its compliance with tracking preferences.

Tracking Compliance and Scope (W3C Working Draft 14 November 2011) defines the meaning of a "do not track" preference and will set out practices for websites to comply with this preference.

These are very early drafts, with many unresolved issues. W3C hopes to have adopted standards by June 2012, but in the meantime is inviting review and comment. For websites hoping to adopt and promote compliance with this proposal, now is a good time to start defining a project with a view to firming up the requirements in April 2012 when a candidate recommendation will be published. The broad requirements can be seen from the current documentation.

Posted on: 15 November 2011 at 08:31 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

12 August 2011

The Lush Topic of Security, Data Protection and PCI DSS

Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Photograph of the entrance and display windows of a Lush Cosmetics shop in London

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

  1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
  2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
  3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
  4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
  5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

Our website (www.lush.co.uk) is now operating under level one PCI-DSS compliance. If you don't have your geek-speak handbook around, that means Personal Card Industry - Data Security Standard. Level one is the highest level achievable; we don't want to take any risks with our customers' money or data. Although this doesn't guarantee that our website is impervious to hacking, it does guarantee that your card details are safe and secure. You can read more about PCI compliance here [missing link]

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...

Posted on: 12 August 2011 at 08:22 hrs

Comments Comments (2) | Permalink | Send Send | Post to Twitter

05 August 2011

Authentication in an Internet Banking Environment

In 2005, the US Federal Financial Institutions Examination Council (FFIEC) published Authentication in an Internet Banking Environment building on their earlier work on electronic banking. A supplement to the 2005 guidance has now been published.

Photograph of screened fencing around a construction site with a sign stating 'Access forbidden to unauthorised persons', with a chain and lock joining two sections of the fence

The 2005 guidance recommended periodic risk assessments so that control mechanisms can be adjusted to respond to changing internal and external threats. The guidance stated that authentication techniques should be appropriate to the risks associated with the product or service, but that single-factor authentication is inadequate. It also recommended building customer awareness, and minimum supervisory expectations for authentication controls relating to high-risk online transactions involving customer information and the movement of funds to other parties.

On 28th June 2011, the FFIEC announced its Supplemental Guidance on Internet Banking Authentication to reinforce the guidance's risk management framework and update the expectations for authentication, layered security and other controls in an increasingly hostile environment.

The supplementary guidance reiterates the need for risk assessments and authentication for higher-risk transactions. It also recommends a layered security approach "since virtually every authentication technique can be compromised". Its recommendations for layered security controls include fraud detection & monitoring, dual device authentication, out-of-band verification, positive pay & debit blocks, transactional limits, activity limits, geo-location IP address reputation monitoring, policies & processes for handling compromised devices and malicious users, monitoring of account maintenance activities and customer education.

So, useful information, and not just for internet banking. The guidance is a good reference source for anyone considering authentication controls for access to more sensitive information.

Thank you to Alexis Fitzgerald for bringing this document to my attention.

Posted on: 05 August 2011 at 08:36 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Policies : Web Security, Usability and Design
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Requested by 54.196.69.189 on Thursday, 24 April 2014 at 11:59 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2014 clerkendweller.com