20 February 2015

Standards

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

15 October 2013

27001:2013 Is Out

ISO/IEC 27001:2013 has been published, superseding the previous 2005 release.

Photograph of bright red rose hips on a country road verge

ISO/IEC 27001:2013 specifies requirements for establishing, implementing, maintaining and continually improving an organisation-wide information security management system (ISMS).

Dejan Kosutic has published a summary infographic of the major changes on his blog. Yesterday he published a further post on transitioning from the 2005 to the 2013 revision.

ISO/IEC 27001:2013 can also be purchased from BSI.

Posted on: 15 October 2013 at 09:11 hrs

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

09 October 2013

Microsoft SDL in the US Financial Services Sector

Microsoft has published a survey commissioned from The Edison Group which examines application development security in the US financial services sector.

Title page from the paper 'Microsoft Security Development Lifecycle Adoption: Why and How'

Microsoft Security Development Lifecycle Adoption: Why and How examines the adoption of Microsoft's process-driven Security Development Lifecycle (SDL) in this sector, the approaches taken, integration methods and looks at the benefits realised. The researchers interviewed a number of companies that use MS SDL.

I found the survey's most useful parts are the list of adopters' best practices and lessons learned. The case studies are perhaps too short to be of any significance, and the second one referring to using SDL for open source development almost seems to have been included to put the idea of using open source tools down, rather than contributing to the "why and how" of the report's title. Unnecessary and wasted space in the document.

Read, compare and contrast. Then consider how these types of things might work within your own organisation and with particular teams.

The paper also refers to the previously mentioned BITS Software Assurance Framework from the Financial Services Roundtable, and Part 1 (Overview and Concepts) of ISO 27034, but not other sources.

Posted on: 09 October 2013 at 08:52 hrs

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

24 September 2013

OWASP ASVS for Web Applications 2013 Beta Release

OWASP's less well known, but immensely useful, Application Security Verification Standard (ASVS) for web applications has been updated and a beta version was released just prior to AppSec EU last month.

Diagram from the OWASP ASVS Web Application Standard 2013 showing the four different web application security verification levels

The ASVS Web Application Standard 2013 defines a set of technical controls for applications that should be verified as part of security testing processes. They are primarily application controls but also include relevant ones in the host environment. The document describes three use cases — for application certification, for alignment of testing methodology and for selection of external suppliers.

The number of classes requirements has been expanded to 13, and now covers:

  • Authentication
  • Session management
  • Access control
  • Input validation
  • Cryptography at rest
  • Error handling and logging
  • Data protection
  • Communications
  • HTTP
  • Malicious controls
  • Business logic
  • Files and resources
  • Mobile.

Each class includes around 10-20 specific requirements. The new sections, and re-allocation of some requirements means that the numbering has changed significantly. The cross-referencing will be important for those already using the ASVS Web Application Standard 2009.

Not all the requirements need to be achieved for every application. The choice can clearly be organisation-specific, based on its own risk assessment, but the document describes four levels of verification, each successive level increasing the number of mandatory requirements.

The project team, primarily Andrew van der Stock, Sahba Kazerooni, Daniel Cuthbert, and Krishna Raja, are working on gathering feedback from the community, creating use-case examples, and mapping to other OWASP projects such as the upcoming new Developer and Testing Guides.

Please help by providing your own ideas to finalise the beta release via the project's mailing list.

Posted on: 24 September 2013 at 08:34 hrs

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

31 March 2013

OWASP Codes of Conduct Stable Release

I am pleased to announce that the six OWASP Codes of Conduct documents have been successfully reviewed and are now stable quality releases.

Partial screen capture of the OWASP Codes of Conduct Project page on owasp.org

Formal reviews of the project were undertaken by Fabio Cerullo and Sebastien Deleersnyder, with the help of Larry Conklin.

The Codes of Conduct define a set of minimal requirements for six types of organizations active in the application security space, specifying what OWASP believes to be the most effective way to support its mission. These requirements are called a "code of conduct" to imply that these are normative standards, in that they represent a minimum baseline, and are not difficult to achieve.

As mentioned previously, I have largely been the custodian of these documents, which were mainly conceived and generated during OWASP Summit 2011 in Portugal. The primary authors and contributors to each document are:

  • Jeff Williams for creating the following three documents, together with and all the participants in the working sessions on Outreach to Educational Institutions, and Minimal AppSec Program for Universities, Governments and Standards Bodies at the OWASP Summit 2011 in Portugal for their ideas and contributions to this effort. Reviewed by Dinis Cruz, Dave Wichers and myself for:
    • OWASP Green Book - The OWASP Application Security Code of Conduct for Government Bodies
    • OWASP Blue Book - The OWASP Application Security Code of Conduct for Educational Institutions
    • OWASP Yellow Book - The OWASP Application Security Code of Conduct for Standards Groups
  • Myself for:
    • OWASP Purple Book - The OWASP Application Security Code of Conduct for Trade Organizations
  • Jason Taylor, Jason Li , Martin Knobloch, Matthew Chalmers, and Justin Searle for creating the document, and all the participants in the working session on Certification at the OWASP Summit 2011 in Portugal:
    • OWASP Red Book - The OWASP Application Security Code of Conduct for Certifying Bodies
  • Jeff Williams and myself for:
    • OWASP Gray Book - The OWASP Application Security Code of Conduct for Development Organizations

Please use the project mailing list to correspond ideas, suggestions and questions about these.

Posted on: 31 March 2013 at 22:39 hrs

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

19 March 2013

Data Protection Risks for Mobile Apps

The European Commission's Article 29 Working Party on the Protection of Individuals has published its opinion on data protection risks for mobile apps.

Partial image of the recommendations for app developers in the European Commission's Article 29 Working Party on the Protection of Individuals 'Opinion 02/2013 on Apps on Smart Devices'

Opinion 02/2013 on Apps on Smart Devices describes the roles, risks and responsibilities of four groups: app developers, operating systems/device manufacturers, app stores and third parties. It seems slightly odd to lump together "rganisations that outsource the app development and those companies and individuals building and deploying apps", and think this will lead to confusion.

However, in the conclusions on pages 27-28, there are two useful lists under the headings "App developers must" and "The Working Party recommends that app developers", which would be suitable for consideration of inclusion within internal compliance standards for app development.

Posted on: 19 March 2013 at 08:28 hrs

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

29 January 2013

Anti Information Warfare Resources (US Federal)

The US Department of Defense's Cyber Security and Information Systems Information Analysis Center (CSIAC) has updated its chart about references concerning information warfare defences.

Small-scale image of the whole CSIAC Information Assurance (IA) Policy Chart - follow the PDF link below to view the chart at larger scales

The Cyber Security and Information Systems Information Analysis Center (CSIAC) is one of eight Department of Defense Information Analysis Centers (IACs) sponsored by the Defense Technical Information Center (DTIC). CSIAC was formed from the consolidation of three legacy IAC's - the Information Assurance Technology Assurance Center (IATAC), the Data and Analysis Center for Software (DACS), and the Modeling and Simulation Information Analysis Center (MSIAC) - along with the addition of the new technical domain of Knowledge Management and Information Sharing.

Sometimes digging through lists of NIST's Special Publications can be time-consuming, or you cannot find an information security regulation mentioned in a contract. The publicly available Information Assurance (IA) Policy Chart (PDF) lists and links to national and federal cyber security related policies and other guidance. The acronym "GIG" is used, meaning Global Information Grid. Topics include:

  • Procurement
  • Development
  • Education and awareness
  • Communications
  • Access control
  • Information sharing
  • Operations
  • Defensive measures
  • Risk management
  • Incident preparedness

Regardless of whether your organisation is based in the United States, has dealings there, if it is in the governmental sector or not, this is a helpful summary of materials that will assist your own information security efforts.

Posted on: 29 January 2013 at 07:41 hrs

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

18 January 2013

Proposed Amendments to EU Data Protection Framework

MEP Jan Philipp Albrecht, Rapporteur to the European Parliament's Committee on Civil Liberties, Justice and Home Affairs has published a report with suggested amendments to the EU Data Protection Framework proposals.

These might well add to the concerns of the UK's Justice Committee, and certainly from the advertising industry around the issue of explicit consent and a widening of the definition of personal data, including in some circumstances "Internet Protocol addresses, cookie identifiers and other unique identifiers".

The report outlines the current text proposed by the Commission, the proposed amendment and justification for the proposed change. Apologies for the length of this post, but some of the more important suggested amendments for web site and web service operators are outlined below to give a flavour of what might be expected.

  • 14 "... The principles of data protection should not apply to data rendered anonymous in such a way that the data subject is no longer identifiable"
    changed to
    "... This Regulation should not apply to anonymous data, meaning any data that can not be related, directly or indirectly, alone or in combination with associated data, to a natural person or where establishing such a relation would require a disproportionate amount of time, expense, and effort, taking into account the state of the art in technology at the time of the processing and the possibilities for development during the period for which the data will be processed."
  • 15 "When using online services, individuals may be associated with online identifiers provided by their devices, applications, tools and protocols, such as Internet Protocol addresses or cookie identifiers. This may leave traces which, combined with unique identifiers and other information received by the servers, may be used to create profiles of the individuals and identify them. It follows that identification numbers, location data, online identifiers or other specific factors as such need not necessarily be considered as personal data in all circumstances."
    changed to
    "When using online services, individuals may be associated with one or more online identifiers provided by their devices, applications, tools and protocols, such as Internet Protocol addresses, cookie identifiers and other unique identifiers. Since such identifiers leave traces and can be used to single out natural persons, this Regulation should be applicable to processing involving such data, unless those identifiers demonstrably do no relate to natural persons, such as for example the IP addresses used by companies, which cannot be considered as 'personal data' as defined in this Regulation."
  • 31 "In order for processing to be lawful, personal data should be processed on the basis of the consent of the person concerned or some other legitimate basis, laid down by law, either in this Regulation or in other Union or Member State law as referred to in this Regulation."
    changed to
    "In order for processing to be lawful, personal data should be processed on the basis of the specific, informed and explicit consent of the person concerned or some other legitimate basis, laid down by law, either in this Regulation or in other Union or Member State law as referred to in this Regulation."
  • 19 "In order to ensure free consent, it should be clarified that consent does not provide a valid legal ground where the individual has no genuine and free choice and is subsequently not able to refuse or withdraw consent without detriment."
    changed to
    "In order to ensure free consent, it should be clarified that consent does not provide a valid legal ground where the individual has no genuine and free choice and is subsequently not able to refuse or withdraw consent without detriment. The use of default options which the data subject is required to modify to object to the processing, such as pre-ticked boxes, does not express free consent."
  • 25 New "The interests and fundamental rights of the data subject override the interest of the data controller where personal data are processed in circumstances where data subjects do not expect further processing, for instance when a data subject enters a search query, composes and sends an electronic mail or uses another electronic private messaging service. Any processing of such data, other than for the purposes of performing the service requested by the data subject, should not be considered in the legitimate interest of the controller."
  • 45 New "The right to the protection of personal data is based on the right of the data subject to exert the control over the personal data that are being processed. To this end the data subject should be granted clear and unambiguous rights to the provision of transparent, clear and easily understandable information regarding the processing of his or her personal data, the right of access, rectification and erasure of their personal data, the right to data portability and the right to object to profiling. Moreover the data subject should have also the right to lodge a complaint with regard to the processing of personal data by a controller or processor with the competent data protection authority and to bring legal proceedings in order to enforce his or her rights as well as the right to compensation and damages resulting of an unlawful processing operation or from an action incompatible with this Regulation. The provisions of this Regulation should strengthen, clarify, guarantee and where appropriate, codify those rights."
  • 54 "To strengthen the 'right to be forgotten' in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform third parties which are processing such data that a data subject requests them to erase any links to, or copies or replications of that personal data. To ensure this information, the controller should take all reasonable steps, including technical measures, in relation to data for the publication of which the controller is responsible. In relation to a third party publication of personal data, the controller should be considered responsible for the publication, where the controller has authorised the publication by the third party."
    changed to
    "To strengthen the 'right to erasure and to be forgotten' in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public without legal justification should be obliged to take all necessary steps to have the data erased, but without prejudice to the right of the data subject to claim compensation."
  • 61 "The protection of the rights and freedoms of data subjects with regard to the processing of personal data require that appropriate technical and organisational measures are taken, both at the time of the design of the processing and at the time of the processing itself, to ensure that the requirements of this Regulation are met. In order to ensure and demonstrate compliance with this Regulation, the controller should adopt internal policies and implement appropriate measures, which meet in particular the principles of data protection by design and data protection by default."
    changed to
    "The protection of the rights and freedoms of data subjects with regard to the processing of personal data require that appropriate technical and organizational measures are taken, both at the time of the design of the processing and at the time of the processing itself, to ensure that the requirements of this Regulation are met. In order to ensure and demonstrate compliance with this Regulation, the controller should adopt internal policies and implement appropriate measures, which meet in particular the principles of data protection by design and data protection by default. The principle of data protection by design require data protection to be embedded within the entire life cycle of the technology, from the very early design stage, right through to its ultimate deployment, use and final disposal. The principle of data protection by default requires privacy settings on services and products which should by default comply with the general principles of data protection, such as data minimisation and purpose limitation."
  • 84 "'data subject' means an identified natural person or a natural person who can be identified, directly or indirectly, by means reasonably likely to be used by the controller or by any other natural or legal person, in particular by reference to an identification number, location data, online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that person;"
    changed to
    "'data subject' means an identified natural person or a natural person who can be identified or singled out, directly or indirectly, alone or in combination with associated data, by means reasonably likely to be used by the controller or by any other natural or legal person, in particular by reference to a unique identifier, location data, online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, social or gender identity or sexual orientation of that person;"
  • 106 New "4a. Consent looses its effectiveness as soon as the processing of personal data is no longer necessary for carrying out the purpose for which they were collected. "

The topic of information security is also addressed:

  • 39 "The processing of data to the extent strictly necessary for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted data, and the security of the related services offered by, or accessible via, these networks and systems, by public authorities, Computer Emergency Response Teams - CERTs, Computer Security Incident Response Teams - CSIRTs, providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the concerned data controller. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping 'denial of service' attacks and damage to computer and electronic communication systems."
    changed to
    "The processing of data to the extent strictly necessary for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist accidental events or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted data, and the security of the related services offered by these networks and systems, by public authorities, Computer Emergency Response Teams - CERTs, Computer Security Incident Response Teams - CSIRTs, providers of electronic communications networks and services and by providers of security technologies and services, in specific incidents, constitutes a legitimate interest of the concerned data controller. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping 'denial of service' attacks and damage to computer and electronic communication systems. The processing of personal data to restrict abusive access to and use of publicly available network or information systems, such as the blacklisting of Media Access Control (MAC) addresses or electronic mail addresses by the operator of the system, also constitutes a legitimate interest."

While not all these amendments (or the rest of the draft framework itself) will come into law, it would be a brave organisation not to start taking these types of considerations into planning and upcoming projects.

Posted on: 18 January 2013 at 08:00 hrs

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

29 June 2012

PCI DSS Requirement 6.2 and Severity Ranking Spaghetti

The week after next OWASP AppSec EU begins in Athens where I am speaking. During my presentation I will discuss the newly mandatory requirement 6.2 in PCI DSS relating to ranking of vulnerabilities, with special emphasis on ranking the severity of vulnerabilities in software applications.

Requirement 6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.

In Tricolour Alphanumerical Spaghetti I will also describe alternative ways of meeting PCI DSS v2.0 Requirement 6.2 and which is a mandatory requirement from 30th June tomorrow, previously just being considered a best practice. I will discuss risk ranking schemes and how to develop a method for evaluating vulnerabilities and assigning a risk rating relevant to your own specific environment and business needs.

PCI DSS requirement 6.2 influences other requirements where the prioritisation of vulnerabilities are referenced:

  • 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
  • 6.5.6 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following: ... All "High" vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).
  • 10.4 Using time synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
  • 11.2.1 Perform quarterly internal vulnerability scans.
  • 11.2.3 Perform internal and external scans after any significant change.

So, I am hoping it will be of use to those with PCI DSS obligations, as well as to organisations who simply want to know what the severity rating of a vulnerability, flaw, fault or weakness means. The presentation is being given at 15:20 hrs on Thursday 12th in the "Builders" track.

Immediately prior to the conference there are training courses. There are still some places left on my course Application Attack Detection & Response — A Hands-on Planning Workshop being held on Tuesday 10th July. This will be a highly interactive day with generous learning opportunities. Last time we did the course, the participants really enjoyed it and gave great feedback.

If you are going for the conference, why not take the opportunity to receive some training. On the next day, Wednesday, you could also register for the training course Elite Web Defense — How to Build Robust and Secure Web Applications being run by the excellent Jim Manico and Eoin Keary. Register for the training and conference here.

Posted on: 29 June 2012 at 08:25 hrs

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

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

14 February 2012

[In]Vulnerable SDLC

Weaknesses in software security? Long-term security advocate and practitioner Eoin Keary has written an article about the weaknesses in our approach to application security.

Construction staff waiting to begin their night shift outside the new Thameslink 2000 station at Farringdon in Clerkenwell, London, UK

Eoin describes the problems with past and current approaches, and has come to believe organisations should use a structured and repeatable method for addressing security in the software development lifecycle (SDLC) encompassing:

  • Secure design
  • Developer training
  • Common module/framework design and implementation
  • Code review
  • Integrated functional/security/anti-functional testing.

He also proposes that manual efforts are used in the SDLC, and in verification activities for runtime scanning, rather than in undertaking manual penetration testing. Eoin also highlights the need for ongoing, continuous monitoring, feedback and analysis in what he terms Enterprise Security Intelligence (ESI) — maybe that is Eoin's Secret Ingredient?

Read, learn, respond and implement what will work with your own organisation's risks and culture.

Posted on: 14 February 2012 at 07:22 hrs

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

More Entries

Standards : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by 54.161.155.142 on Sunday, 29 March 2015 at 11:38 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 https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk