02 July 2015

Policies

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

02 September 2014

IEEE's Top Software Security Design Flaws

Last week the IEEE Computer Society has published a report describing the top software security design flaws, from discussions in a workshop held earlier this year.

Title on the cover of the IEE Computer Society Report 'Avoiding the Top 10 Most Significant Software Security Design Flaws'

Avoiding the Top 10 Most Significant Software Security Design Flaws identifies problem with the design of software that leads to security flaws; not issues arising from poor or coding or deployment.

The software security design flaws identified are:

  • Earn or give, but never assume, trust
  • Use an authentication mechanism that cannot be bypassed or tampered with
  • Authorize after you authenticate
  • Strictly separate data and control instructions, and never process control instructions received from untrusted sources
  • Define an approach that ensures all data are explicitly validated
  • Use cryptography correctly
  • Identify sensitive data and how they should be handled
  • Always consider the users
  • Understand how integrating external components changes your attack surface
  • Be flexible when considering future changes to objects and actors.

The report is published under a Creative Commons BY-SA licence.

Posted on: 02 September 2014 at 10:19 hrs

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

13 June 2014

Characterising Fraudulent Online Customers

Payment processor 2Checkout has launched a new quarterly report detailing payment fraud trends.

Partial view of one of the charts from 2Checkout Fraud Index 2014Q1

2Checkout Fraud Index 2014 Quarter 1 contains information from the company's own checkout and payment fraud monitoring systems, cross tabulated against other observed buyer characteristics.

The report includes data on and ranks buyer fraud by:

  • Credit card issuer
  • Billing address
  • IP address
  • Currency
  • Cross border status
  • Product type
  • Value of transaction.

Any prior national prejudices might be challenged. Useful stuff if your are running your own online fraud monitoring system and setting thresholds for potential fraud alerts.

Posted on: 13 June 2014 at 09:35 hrs

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

03 June 2014

Personal Data Protection in Online Systems - Part 2/2 Security Controls

Yesterday I described the new report from the ICO, Protecting Personal Data in Online Services: Learning From the Mistakes of Others. Below is a list of the matching security controls for each issue mentioned in the report.

Examining the ICO report in greater detail, provides additional clues about the requirements expected in each class of vulnerability. The report "is not aimed at experienced security professionals", but rather at those responsible for the security of the online systems, and hopefully this list will be useful to those individuals.

My breakdown of the matching security controls, based on my interpretation of the report's text, are listed below.

Issue from ICO Security Report Derived Security Controls
Failure to keep software security up to date
  • Create and maintain a policy for software patching
  • Maintain a list of all software, including components (e.g. third-party libraries, frameworks), their versions, source and method of monitoring for security patches and other updates
  • Define who is responsible for the patching of each software component
  • Create, use and maintain a procedure for assessing security patches and other software updates, that includes a risk assessment
  • Apply software security patches in a timely manner
  • Do not use software that is no longer supported by the supplier/vendor/development company; or limit its use and undertake a risk assessment and apply additional controls
  • Create, maintain and operate a process for checking that security patches have been applied to all software components, or those that have not been applied have adequately justified, documented and applied mitigating controls
Lack of protection from SQL injection
  • Create and maintain a process for other people and organisations to report security issues about your applications
  • Create and maintain a procedure for assessing and fixing security flaws in custom application code, and include these issues in the software patching documentation (see above), and if SQL injection is found in one place, examine similar code elsewhere
  • Identify who is responsible for preventing SQL injection in each custom coded application (e.g. software such as websites developed by/for the organisation)
  • Require the default to be to use the safest server-side method for database queries supported by the API or framework
  • Ensure the prevention, detection and remediation of SQL injection vulnerabilities are included at multiple stages of the software development lifecycle (e.g. coding standards, peer/independent code review with audit trail, automated code review, automated vulnerability assessment, penetration testing before going live)
  • Use the software patching policy and processes (see above) for software components used by the custom applications
  • Include a requirement in contracts with third party development to build security into their development practices and inform you when they become aware critical vulnerabilities like SQL injection, and then provide patches
  • Use automated application vulnerability assessments (scanning) to help identify SQL injection, but ensure these cover all the application (e.g. for authenticated customers and administrators too)
  • Undertaking penetration testing in the production/live environment of custom-built applications (external and internal-facing) that interact with databases and other data stores, and repeat periodically
Exposure of unnecessary protocols & services
  • Do not use insecure protocols such as Telnet and plain FTP
  • Implement access control for all protocols (e.g for secure FTP disallowing anonymous access, preventing SMTP being used as an open relay)
  • Use firewalls to prevent external access to internal services
  • Remove, disable or block un-necessary services (see also decommissioning below)
  • Limit remote access to trusted IP addresses and enforce access using an encrypted method
  • Segment services so that a compromise of one does not lead to wider system compromise
  • Consider using a Virtual private Network (VPN) using strong credentials (such as two-factor authentication) for all remote access
  • Scan ports of all system components periodically to verify that only the intended services are available externally, internally, and from particular other locations
  • Document and periodically review all the services allowed
Exposure of decommissioned software/services
  • Maintain a schedule of all software/services in use
  • Ensure all system components (hardware, software, configuration files, databases, files, services, ports, DNS records, etc) are decommissioned when no longer needed, and maintain a record of how this was undertaken
  • Test/audit that decommissioned components no longer exist and cannot be accessed
  • For hardware disposal, ensure data is securely removed
Insecure storage of passwords
  • Create and maintain a password policy for all types of system users
  • Encourage, and allow, users to choose stronger passwords
  • Discourage users from having the same password on multiple systems
  • Discourage or prevent commonly used passwords
  • Never store or send passwords in plain text
  • Never encrypt passwords unless there are extremely robust key protection and key management processes in place
  • Use one-way hashing of passwords with a long salt value, unique for each user
  • Use a hashing method that is slow (e.g. PBKDF2, bcrypt or scrypt)
  • Do not use weak hashing methods such as MD5 or SHA-1
  • Review hashing best practice periodically, and build in considerations to allow future changes to the hashing method
  • Ensure password breaches are included in incident report planning
Failure to encrypt online communications
  • Identify and record all information that should be encrypted in transit
  • Ensure the encryption method (e.g. SSL/TLS) is configured correctly and that certificate are valid
  • Maintain a list of all certificates and ensure they are renewed before expiry
  • Consider using Extended Validation (EV) digital certificates to provide a higher level of identity assurance to users
  • Do not use SSL v2, and preferably enable TLS 1.2), disable weak ciphers (i.e.enable ciphers with 128 bi strength or greater) and avoid weak ciphers (e.g. RC4) or those that provide no encryption or no authentication i.e. null ciphers)
  • Ensure the information cannot be accessed without encryption
  • When web pages are sent over SSL/TLS, ensure every single component in the page (e.g. images, style sheets, scripts and third-party hosted content) is also sent over SSL/TLS
  • Never send session identifiers (e.g. cookies identifying an authenticated user) over unencrypted connections
  • Ensure SSL/TLS websites are only accessible by hostnames included in the certificate, and not by IP address)
  • Consider making websites completely "SSL/TLS only
  • Review transport encryption best practice periodically and update configurations as required
Processing data in inappropriate locations
  • Identify and maintain an inventory of all locations where personal data is stored, processed and transmitted
  • Do not allow unauthorised access (e.g. public access) to personal data
  • Do not use production data in development and test systems
  • Incorporate personal data access into systems design processes
  • Use network segmentation to assist with limiting access to personal data (e.g. segregate non production systems, segregate teams or departments with access to sensitive personal data)
  • Use redundancy/diversity to protect against accidental loss or destruction of, or damage to, personal data
  • Create and maintain policies for the storage, processing and transmission of personal data
  • Create, maintain and use procedures for transfers of personal data
  • Do not place copies of personal data in unprotected locations
  • Enforce appropriate access control in custom applications (e.g. websites)
  • Provide training about the access, use and transfers of personal data
  • Monitor transfers of personal data
Use of default credentials including passwords
  • Change all default passwords across all system components
  • Disable or remove guest and demonstration accounts
  • Use strong passwords to replace default ones (see above)
  • Avoid hard coding of access credentials (and never in software code), but use encryption if possible if necessary to store elsewhere (e.g. configuration files)

So, not such a short list. It is a combination of technical, administrative and physical controls, and not just applicable to online systems, but all electronic systems that store, process and transmit personal data, and generally regardless of whether it is sensitive personal data or not.

Posted on: 03 June 2014 at 07:48 hrs

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

02 June 2014

Personal Data Protection in Online Systems - Part 1/2 Security Vulnerabilities

The UK's Information Commissioner's Office (ICO) published a report in mid May about the most common classes of IT security vulnerabilities in online systems that result in failures to secure personal data.

The cover from the ICO report

The seventh data protection principle requires organisations to take appropriate measures to safeguard personal data. It states "Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data".

Protecting Personal Data in Online Services: Learning From the Mistakes of Others describes the issues most commonly found to have been the root causes of inadequate protection of personal data in online systems.

There are some issues clearly related to poor management control such as incorrect decommissioning of business processes and inappropriate locations for processing of data. The other issues are more technical but are all the types of things well-organised and careful organisations ought to be getting right already.

I was interested to check which of these relate to infrastructure (I/S) components and which to applications (Apps). For the latter, also whether the latter appear in the OWASP Top Ten most critical risks.

Issue ICO Security Report Component OWASP Top Ten 1013
I/S App
Failure to keep software security up to date Y Y A9 Using components with known vulnerabilities
Lack of protection from SQL injection Y A1 Injection
Exposure of unnecessary protocols & services Y - -
Exposure of decommissioned software/services Y Y - -
Insecure storage of passwords Y A6 Sensitive data exposure
Failure to encrypt online communications Y Y A6 Sensitive data exposure
Processing data in inappropriate locations Y - -
Use of default credentials including passwords Y Y A5 Security misconfiguration

We can see there is a mixture of infrastructure and application security issues, and that some issues span both of these categorisations.

Simon Rice, ICO Group Manager, blogged about the release of the report, password storage, SQL injection, and answers questions about the report in a video interview.

Tomorrow, I will list the security controls for each issue, as discussed in the report.

Posted on: 02 June 2014 at 07:40 hrs

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

25 February 2014

SANS 2014 Report on Application Security Programmes

The SANS Institute has published the results of a survey about application security programmes.

Partial screen capture of one of the charts from the SANS report 'Survey on Application Security Programs and Practices'

The researchers Jim Bird and Frank Kim stated the goals were to discover:

  • How widespread and mature application security programs are
  • Their effectiveness
  • What tools and practices are being utilised through the development lifecycle and which are most useful
  • How training is being undertaken and its effectiveness
  • How much is being spent on application security, where and whether this is aligned with organisational risk
  • What are the organisations' future plans for application security

488 respondents provided the data summarised in the report, with a quarter of these working in very large enterprises of more than 15,000 people and 39% from organisations with 1,000 or less people. 30% of respondents had development teams with less than 25 staff, and 6% had no developers at all, with all software development being outsourced.

The published report can be downloaded free of charge at SANS Survey on Application Security Programs and Practices.

The survey found that although organisations are investing more in application security, it is not particularly effective, and that root causes are not being addressed and instead there is still a reliance on mitigating software vulnerabilities after deployment. I recommend reading the findings and conclusions in full.

There was another document referenced in the report which I was not aware of. The US-based Financial Services Information Sharing and Analysis Centre has published a useful white paper titled Appropriate Software Security Control Types for Third Party Service and Product Providers to improve software security control practices.

Posted on: 25 February 2014 at 07:15 hrs

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

29 January 2014

Privacy Notices and Supplier Contracts

Over Christmas I caught up with a backlog of news stories, tweets and bookmarked items. One relating to privacy notices surprised me, despite being quite an old item.

Photograph of a locked wooden door with an adjacent metal enclosure housing a keypad, video camera, microphone and loudspeaker - a sign on the door reads 'Keep locked shut' and another handmade sign reads 'Visitors - Please press buzzer and show ID to  the camera - thank you'

It seems Google's terms of service (UK version) for Google Analytics include certain privacy requirements on its users (web site operators).

The web post identifies obligations placed on web site operators:

  • Have a privacy policy
  • Abide by all applicable laws relating to the collection of information from visitors
  • State the usage of third party tracking and usage of cookies for tracking

There are additional requirements for users of AdWords and AdSense. A handy reminder that your suppliers can be the source of additional information security and privacy mandates.

After all, if you have an incident, you don't want to be found breaking contractual obligations as well.

Posted on: 29 January 2014 at 08:35 hrs

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

15 June 2013

Enterprise Application Usage

Have you ever wondered what applications are typically being used in enterprise-scale organisations and what the risks are? A report by Palo Alto Networks has analysed over 3,000 worldwide traffic assessments to produce an aggregated summary report.

Partial screen capture showing the interactive tool published to allow the data to be examined dynamically

This is the first of three posts relating to publications that came out some time ago — I am just catching up, but hopefully they are worth mentioning. This first post relates to the oldest, a report published in February.

The Application Usage and Threat Report, 10th Edition provides regional data on the use of personal, business and custom/other applications on enterprise networks. The last category relates to 8-10% traffic that does not match any known application such as a custom internal application or a commercial application not yet identified in the assessment, and could include malware. The report provides data on:

  • Usage of applications by category (e.g. social networking, file sharing, photo, video)
  • Application functionality overlap
  • Bandwidth usage by category
  • Malware and exploit prevalence
  • Use of transport layer security.

The conclusions include that social networking, file sharing and video applications are not the most common threat vectors; attackers are masking their activities through custom or encrypted applications. The report's data can be analysed dynamically using a well-designed online tool where the data point information is viewable for each chart element.

Posted on: 15 June 2013 at 10:30 hrs

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

05 April 2013

Fair Data?

At the end of January, the Market Research Society (MRS) launched an initiative called Fair Data.

Photograph from the London Shard at dusk looking towards Canary Wharf

Existing MRS Company Partners (who are already subject to the MRS Code of Conduct), and others who apply and pass an assessment by the MRS of their "policies and procedures", must firstly adhere to the 10 principles and secondly must "use the Fair Data mark in all relevant dealings with customers and respondents". The 10 principles relate to the following topics:

  1. Consent
  2. Purpose
  3. Access
  4. Security
  5. Respect
  6. Sensitive personal data
  7. Supply chain
  8. Ethics
  9. Staff training
  10. Default to not using personal data unless there is adherence to the above nine principles

So the scheme does not include all eight data protection principles but some extra business process requirements. Perhaps this is because the trust mark has been designed "to be used internationally".

The scheme seems to have some initial endorsements, but these type of things won't work unless there is a large adoption so that consumers and others recognise the mark, and that is backed up by verifiable evidence that it makes a difference. I am not sure if this "kite mark" or "trust seal" is the one to make everyone confident about use of their personal data.

Posted on: 05 April 2013 at 18:32 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

18 December 2012

Disposal

Just in case you have got the development process running slickly, and operation is going smoothly, have you thought about asset disposal, and related data destruction, at the end of life?

Photography of a few autumnal-coloured leaves on a lichen-covered tree

Well, the UK's Information Commissioner has produced a short guide IT Asset Disposal for Organisations.

As it states in the guide "if personal data is compromised during the asset disposal process, even after it has left your organisation, you may still be responsible for breaching the DPA so it is important to manage the process correctly". This is of course relevant for other types of data too. And not just your own equipment, but that of organisations processing data on your behalf (and in the cloud).

Who is your "asset disposal champion"?

Posted on: 18 December 2012 at 06:58 hrs

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

More Entries

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

Requested by 54.91.93.213 on Thursday, 30 July 2015 at 17:07 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