Thursday 26 December 2013

OWASP Switzerland Chapter Meeting December 2013

OWASP Switzerland

Highlights

At our recent chapter meeting (including beer and addictive crisps*), which was kindly hosted by Credit Suisse in Zürich, we had an interesting discussion about application security and OWASP. Obviously no definitive conclusion was reached - but then that is not the point.

Topics included whether OWASP is obsessed with XSS at the expense of other issues. If your application does not have an audit trail, is this as as big a risk as an XSS vulnerability. This could be generalized to ask if there is too much emphasis on the purely technical and not enough on more esoteric issues such as risk etc. It was noted that the OWASP Top 10 is now based on risk and also that the new OWASP CISO project attempts to address more management type concerns.

Discussion was also had about the open/closed source debate and what advantages each had. The consensus seems to be that both are here to stay. Development houses should have programs in place to handle both.

2014  Plans

For 2014 the OWASP Swiss chapter is planning 6 meetings beginning in February and every two months after that. Keep an eye on the mailing list and on the OWASP Switzerland website etc. for more details.
 
As usual if any of you would like to give a talk on any particular topic then don't be shy.

A few ideas:
- Agile development and security
- Risk and application security
- Demos of OWASP products

Useful Links


* Americans call them chips - but they're wrong.


Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Sunday 24 November 2013

PCI PA DSS and General Application Security

Introduction

This blog entry looks at how to use the PCI PA DSS in your general application security program.
 
The PCI PA DSS (Payment Card Industry Payment Application Data Security Standard) version 3 has just been released.   According to the standard:
"The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data and/or sensitive authentication data". 
It applies to software vendors who develop applications which process payment cards (credit or debit cards). This is separate from the main PCI DSS (Payment Card Industry Data Security Standard) which applies to any organization which stores, processes or transmits payment card information. The PA DSS is targeted at developers.

While this is aimed at applications which are used to process payment card information, it can also be used as a general standard for application security. If you are involved in application security, you should have a look at the PA DSS standard because you may get some useful tips from it.

The standard contains 14 requirements. While some of these are specific to payment cards, most of the requirements can apply to general application security. In the requirement simply replace "payment application" by "application" and cardholder data or PAN by "sensitive data" and the contents can apply to any application. The application is the software application that you are developing and "sensitive data" is any sensitive data that your application may be processing e.g. personal information. The phrase "software vendor"  can be replaced by software developer - essentially the team that is developing your application.

What is the best way to use the standard for general application security? When designing your application, go down through each of the requirements in the PA-DSS documents and ask the following types of questions.
  • Does this requirement potentially apply to my application?
  • What is the risk of not implementing this requirement in my application?

Alternatively, if you have a secure development program within your organization, go down through the PA-DSS, perform a gap analysis and see if there are tasks which you should incorporate into your security program.

For example, requirement 5 covers the elements of a secure development program. This should really be the first requirement. Are there sections in requirement 5 which you can incorporate into your program? Requirement 4 covers application audit trails. In particular, it includes the types of information that should be stored in the audit log itself. Audit requirements are often not included in general application security requirements. However this is one area which can be expensive to retrofit but relatively cheap to incorporate if it is included from the beginning of the development.

Download and read the PA-DSS standard itself. Each requirement consists of a number of different subsections. There are 3 columns. Column 1 gives the requirement itself. Column 2 describes the testing procedure that that an auditor or tester would follow to see if the requirement has been implemented correctly.  Column 3 gives general guidance.  In reviewing the standard, you should concentrate on columns 1 and 3.

The following sections give a very brief overview of each of the requirements. However you should download and read the actual standard.

Requirement 1:Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data

This is fairly specific to payment card applications and is probably irrelevant to your application.

Requirement 2: Protect stored cardholder data

Read through the requirement. Where it talks about cardholder data or PANs (Primary Account Number)  replace it with "sensitive data" and see do any of the recommendations apply to your application. Does data need to be encrypted or masked in some way when it is being stored.

Requirement 3: Provide secure authentication features

Secure authentication features apply to any application where authentication is required. It talks about username requirements and the types of password features that may be used.

Requirement 4: Log payment application activity

This requirement covers audit trail considerations. Does your application need an audit trail? In particular, requirement 4.3 covers the data that an application should record. This requirement is often neglected.

Requirement 5: Develop secure payment applications

This covers good development practices and should probably be the first requirement. Production type data should not be used in test systems. It talks about secure code reviews, secure training for developers.  There should be a "formal process for secure development of  applications". Requirement 5.2 covers the OWASP Top 10 type risks.

Requirement 6: Protect wireless transmissions

This is fairly specific to payment type applications and probably does not apply to most general applications.

Requirement 7: Test payment applications to address vulnerabilities and maintain payment application updates 

Test the applications properly and keep them patched.

Requirement 8: Facilitate secure network implementation

Essentially this is saying that the application should not have a negative security impact on the environment in which it is to be deployed. For example it should not require that insecure services such as FTP are needed.

Requirement 9: Cardholder data must never be stored on a server connected to the Internet

Your sensitive application data must be stored securely. It should not be on a server connected directly to the internet.

Requirement 10: Facilitate secure remote access to payment application

If remote access is required to your web application then it should be implemented securely.  Remote access should only be enabled when it is required and should only be allowed from specific ip addresses. Two factor authentication should be implemented. Default usernames and passwords should be changed.

Requirement 11: Encrypt sensitive traffic over public networks

Any sensitive data that your application processes should be encrypted as it travels over the public network. In most cases this means using SSL/TLS over the internet. However note, the standard itself mentions a number of other technologies including bluetooth etc.

Requirement 12: Encrypt all non-console administrative access

Your application should not use technologies such as telnet for administrative access.  SSH, VPN, or SSL/TLS should be implemented.

Requirement 13 and Requirement 14

These probably do not apply to general applications.

Useful Links

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Saturday 26 October 2013

ISO 27001:2013, 27002:2013 and James Joyce

The latest versions of the two ISO flagship standards are now available through ISO and other standards organisations such as BSI

They are a bit like James Joyces's novel "Ulysses".  Everybody agrees it's great, but very few have actually read it.

The problem with the ISO standards is that they are expensive. Each one costs in the region of £100 . They are not for the casual user. On the other hand, they will be valid for the next 7 to 8 years, going by the lifespan previous versions. If you are seriously interested in Information Security, you should consider investing.

Of the two, 27002:2013 is probably the more useful. It lists various security controls that could be implemented across a range of areas.

The site http://www.iso27001security.com/html/27002.html gives a good overview of the contents of the 27002 standard.

If you don't want to fork out the money, then consider looking at the NIST special publication series.These are free. Start with Managing Information Security Risk. This is the flagship document in the series. Section 1.3 links to the other important documents within the special publication series. Note that the NIST documents are meant to align with the ISO standards
"The concepts and principles contained in this publication are intended to implement for federal information systems and organizations, an information security management system and a risk management process similar to those described in ISO/IEC standards"



Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Monday 27 May 2013

So secure that it's insecure

A few months ago, Jeremiah Grossman, WhiteHatSec CEO, gave a detailed account of the efforts he had to go through to get access to his encrypted disk image.  He had forgotten his password.

Luckily, it all worked out in the end. With the help of very smart people, he managed to retrieve the password.

So we know the encrypted disk image was very secure since even he could not access it.

But was it secure?

Let's start with two definitions from ISO 27000:2012

Availability:
property of being accessible and usable upon demand by an authorized entity.

Information Security:
preservation of confidentiality (2.13), integrity (2.36) and availability (2.10) of information

The definitions show us that "availability" is an important aspect of information security. The data must be "available on demand". In this case, the data was clearly not available on demand. Therefore the preservation of availability was not achieved. This means that an information security "event" occurred.

The  encrypted disk image was so secure that it was insecure. The ultimate insider attack.

Agreed, the logic outlined above is a bit contorted, but you get the idea.

Most people think about security in terms of confidentiality - the system was "hacked". However, don't forget that availability is the third leg of the information security triad:
  • confidentiality
  • integrity
  • availability
For a system to be secure, it must preserve all three properties.


Useful Links



Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Monday 20 May 2013

Irish Data Protection Commissioner - Annual Report 2012

The Irish Data Protection Commissioner released his annual report for 2012. It is worth having a quick look through the press release and  report to see what are the current issues. It is especially worth reading the appendix 4 on the INFOSYS system, which gives access to data held within the department of Social Protection's system.

To quote from the press release:
  • "One of the major themes in this year’s report concerns the issue of sharing personal data in the public sector which has featured regularly in previous annual reports from this Office". 
The importance of audit trails is stressed in relation to who accessed data. This is of particular importance in the public sector where you usually don't have a choice as to whether you appear in the database or not. Usually in the private sector, you have some sort of say about the sites that you use.

A number of cases are highlighted where data was accessed inappropriately by users of the INFOSYS system.

In addition, some members of the Police Force are shown to have accessed the PULSE Police system inappropriately to look at information on celebrities.

This matters. 

A few weeks ago, the Irish Independent reported on the powers that the Revenue Commissioners now have. Revenue Commissioners boss Josephine Feehily told a Government committee: 
  • "that tax officials can now trawl through reams of data, including bank accounts and mobile phone numbers, to spot cheats."
This sounds like the kind of stuff that the old East German secret police could only have dreamed of - and it will only get worse. Governance in relation to how public bodies manages personal data is vital. The audits carried out by the Data Protection Commissioner are critical in making sure that there is some sort of proper security in place.
  • How is this data used?
  • Is this data misused and abused?
  • How is the "mobile phone" and "bank account" data made available to the Revenue?
  • Is it deleted when no longer necessary?
  • Who has access to this data?
  • Is there an audit trail of all access?
  • etc.....the list goes on.

One good thing is that the Commissioner says that his office is adequately funded.

Useful links

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Monday 22 April 2013

ICO Breach Statistics 2012

In 2012 the ICO (Information Commissioner's Office) in the UK found 5 websites to be in breach of  data protection act.

The ICO lists the actions that it takes against organizations that it deems to be in breach of the Data Protection act. This also serves as a useful source of statistical information which this blog entry briefly explores. There are a number of different actions that the ICO can take.
  • Monetary Penalty Notices, 
  • Undertakings
  • Enforcement Notices
  • Prosecutions

Overall Statistics

For 2012 here are the overall statistics.



Total for Action
Nr for Web
Application
Monetary Penalty Notices 24 1
Undertakings 29 4
Enforcement Notices 03 0
Prosecutions 06 0
Overall Total 62 5

There were 62 incidents of which 5 relate to websites. Given the number of online applications that process personal information, 5 seems to be a remarkably small number.

Here is a high level overview of the web application incidents.

Monetary Penalty:
  • 6th August: Sensitive personal information relating to 1,373 employees was published on the  website.
Undertakings:
  • 1st March: Disclosure of personal information in training materials published on its website
  • 17th April: a web design error that created the potential for unauthorised access to individual’s personal data 
  • 18th April:  Two data security incidents which relate to the unauthorised disclosure of personal data on the data controller’s website.
  • 30th November: A private area on the website was accessible to members of the public

The Rest of the Incidents

The rest of the cases are made up of a mixture of the usual suspects:
  • Information being sent to the wrong recipient. 
  • Paper files left in waste bins. 
  • Unencrypted memory sticks. 
  • Hard drives not securely erased at end of life.
  • etc.

It is worth taking a look at the ICO website taking actions page to get a feel for the kind of problems that exist. There is no real pattern. Website issues are only a small proportion of the overall numbers. It shows how difficult it can be for a security manager to put a comprehensive security program in place.

Useful Links

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Thursday 18 April 2013

Information Security Error Caused Austerity

The headline of which we dream.

It looks like there was an Excel coding error in one of the main academic papers which brought this age of austerity upon us. The spreadsheet that the authors used is not accurate.

The Roosevelt institute blog has all the dirty details.

Now for the Information Security angle. We all know that information security is about protecting the confidentiality, integrity and availability of

According to ISO 27000, information security is the
  • "preservation of confidentiality, integrity and availability of information"
Also according to ISO27000, integrity is the
  • "property of protecting the accuracy and completeness of assets"
The Roosevelt blog shows that the Excel spreadsheet was not accurate.
Since the accuracy isn't protected, then there is an integrity issue.
And since there is an integrity issue, there is an Information Security issue.

QED.

Imagine having to tell the people of Europe that all these austerity measures are the result of an Information Security problem in an Excel Spreadsheet.

Useful Links




Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Monday 8 April 2013

ISO 2700x Standards on the Cheap(ish)

Most people agrees that ISO 2700x family of security standards are a good idea. But like James Joyce's Ulysses,  how many have actually read it? 

The big problem is that they are  expensive to acquire. A casual user is probably unwilling to fork out the money. Even in big organizations it can be difficult to get hold of the standards.

The two main standards ISO27001:2005 and ISO27002:2005 each cost  Swiss Francs CHF134.-- (approx $143.00)  each on the ISO store. And there are a lot more standards.

 Recently I discovered that you can purchase the main 27001 and 27002 copies of the standards from ANSI for $30 each. See Useful Links below. This is a big saving compared to the standard ISO price. The main difference is that the branding is from INCITS ((InterNational Committee for Information Technology Standards)). The text itself seems to be the same.  Of the two, the 27002 is the more useful, as it lists many best practice security controls or measures that you can implement in your organization. The other ISO2700X standards are not available so cheaply through ANSI.

You can also download ISO/IEC 27000:2012 "Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary" for free.

Useful Links

 


Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Thursday 4 April 2013

Which is it ? - Cyber Attacks cause Huge Losses or no Losses

Do cyber attacks cause real damage or not?


According to Bloomberg:

"The 27 largest U.S. companies reporting cyber attacks say they sustained no major financial losses, exposing a disconnect with federal officials who say billions of dollars in corporate secrets are being stolen." 

Are these companies telling the truth? These reports are based on recent filings with the Securities and Exchange Commission (SEC) so one would imagine they should be fairly honest.

According to the BBC:

"In 2012, the head of MI5 Jonathan Evans said the scale of attacks was "astonishing".

One major London listed company had incurred revenue losses of £800m as a result of cyber attack from a hostile state because of commercial disadvantage in contractual negotiations."


If it's a listed company, would they not have to reveal the loss in their annual report? Does anybody know who this company is?

If you are interested, it's worth reading the paper "Measuring the Cost of Cybercrime" by Ross Anderson and associates.

Useful Links:



Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot