04 March 2014

Architecture

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

18 September 2012

Mobile Payments, Security and PCI Requirements

Applications that accept payments and are installed on consumer mobile devices, not used exclusively used for a single payment application, such as smart phones, tablets and PDAs have been excluded from the PCI SSC's validation programme Payment Application Data Security Standard (PA-DSS). These types of mobile payment acceptance applications are known as Category 3 - payment applications operating on any consumer electronic handheld device that is not solely dedicated to payment acceptance for transaction processing.

Partial image of the chart in Appendix B of 'PCI Mobile Payment Acceptance Security Guidelines' showing the suggested responsibilities for the 18 best practices

Mobile payment Acceptance FAQs, published in June 2011, recommended that Category 3 applications intended for use in the cardholder data environment are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance, until the development of appropriate advice, guidance, and/or standards to ensure that such applications are capable of supporting a merchant's PCI DSS compliance. On Friday the PCI SSC published new guidance for developers.

PCI Mobile Payment Acceptance Security Guidelines v1.0 September 2012, describes firstly 3 objectives and guidance for application payment transactions:

  1. Prevent account data from being intercepted when entered into a mobile device
  2. Prevent account data from compromise while processed or stored within the mobile device
  3. Prevent account data from interception upon transmission out of the mobile device

Secondly, guidance on 15 risks and controls in the supporting environment (mobile platform and associated applications):

  1. Prevent unauthorized logical-device access
  2. Create server-side controls and report unauthorized access
  3. Prevent escalation of privileges
  4. Create the ability to remotely disable payment application
  5. Detect theft or loss
  6. Harden supporting systems
  7. Prefer online transactions
  8. Conform to secure coding, engineering, and testing
  9. Protect against known vulnerabilities
  10. Protect the mobile device from unauthorised applications
  11. Protect the mobile device from malware
  12. Protect the mobile device from unauthorized attachments
  13. Create instructional materials for implementation and use
  14. Support secure merchant receipts
  15. Provide an indication of a secure state

Recognising that no one party has sole responsibility for security of Category 3 applications, a table in Appendix B of the guidance suggests responsibilities for the 18 practices. The responsibilities are assigned to device manufacturers (e.g. Apple, Huawei, Motorola, Nokia, Samsung), operating system developers (e.g. Apple, Google, Microsoft), application developers (e.g. you?), and merchants as end-users or payment acceptance service providers.

The guidance also provides a list of ten additional sources of information to support the guidance. Further advice and standards on mobile payments are expected from the PCISSC in 2013.

In the next post, I will discuss some related updated guidance from Visa.

Posted on: 18 September 2012 at 23:30 hrs

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

16 March 2012

Access Control and Application Security Verification

The next meeting of OWASP London will be on Thursday 29th March from 18:00 for an 18:30 prompt start.

Photograph of a London Underground sign against a dark night sky

Jim Manico will be speaking about Deep Access Control Best Practices and Anti-Patterns, and Manish Saindane about IronWASP, a web application testing platform. These talks sound very useful and I am disappointed that I won't be able to attend that evening.

The event is being held at Morgan Stanley, Canary Wharf. Full details are available on the chapter page. It is free to attend, and everyone is welcome, but prior registration is required to gain access to the building.

Posted on: 16 March 2012 at 09:00 hrs

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

21 September 2011

AppSensor Summit at AppSec USA 2011

Following a successful training course yesterday with great group of delegates, today I attended the OWASP AppSensor Project working group at AppSec USA 2011.

Photograph of downtown Minneapolis where the OWASP AppSec USA 2011 conference is being held

The AppSensor Summit was held to review the project's recent developments and activities, and to gather ideas from existing and new contributors to create a future roadmap. It was good to meet at long last John Melton, AppSensor's lead programmer, and catch up with Michael Coates and Ryan Barnett.

The summit also attracted a diverse range of developers, architects, users and security vendors. There were probably about 10-12 people attending all day, with a few more popping in and out as their timetables and other commitments allowed. The discussions defined the contents for a new book, an AppSensor development life cycle, an integration plan and a new concept to modularise the analysis engine to simplify integration with application software. The idea of creating a set of example usage profiles was also suggested. I think my name is down to help mainly with a new version of the AppSensor book, but I hope I can contribute with some of the interface definitions for interactions with the analysis engine, and possible signalling/exporting functionality.

The meeting notes are available, so if you have any comments or suggestions, please add them there, or discuss them via the project's mailing list.

The talks at the conference begin tomorrow.

Posted on: 21 September 2011 at 22:30 hrs

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

02 July 2010

Web Site Security Basics for SMEs

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Photograph of a waste skip at the side of St John Street in Clerkenwell, London, UK, with the company's website address written boldly across it

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

  • Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
    • check backup data can read and restored periodically
    • don't forget to securely delete data from old backups when they are no longer required
  • Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
    • keep a record of the firewall configuration up-to-date
    • limit who can make changes to the firewall
  • Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
    • remove or disable all unnecessary services and other software
    • delete old, unused and backup files from the host servers
  • Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
    • restrict what each account can do as much as possible
    • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
  • Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
    • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
    • make note of any renewal dates
  • Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
    • verify who legally owns the source code, designs, database, photographs, etc.
    • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

  • Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
    • impose security standards and obligations on suppliers and partner organisations
    • keep an eye open for changes to business processes that affect data
  • Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
    • include configuration details and information about third-party services required
    • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
  • Provide information to the web site's users how to help protect themselves and their data.
    • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
    • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
  • Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
    • web server logs are a start, but customised logging is better
    • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

Posted on: 02 July 2010 at 08:18 hrs

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

12 March 2010

Don't Stop the Attack (Too Soon)

Designers of web sites and web application systems have many places where potential attacks could be detected. But where should attacks be stopped?

There is of course the problem of identifying what is exactly an attack—is it a very malicious payload, a drive-by attack, reconnaissance for something worse to come, a search engine crawler or the submission of a typographical error by a valid user? Sometimes you may not know without correlating data from different sources over a period of time. Having some sort of centralised logging, correlating and alerting system is required.

Take for example a page address (URL) that is only meant to be requested by a particular authorised source (user or system). This might be something like a simple form for suppliers to collect orders, an uptime monitoring target, a data import routine or data exchange facility. Let's assume the application script processing this URL validates the request format, the argument names and values, and source (perhaps by some combination of username, password, token, IP address and certificate). But what should be done if the request comes from an unauthorised source or fails one of the other validation checks?

Such requests could be restricted by a router, network firewall, web application firewall or even restrictions configured on the web server itself. It may seem most appropriate to add rules to the network firewall. In a simple web hosting architecture, this might look like this:

Schematic diagram showing, from left to right, a border router, network firewall and multi-function server (with the web site, application code and database) - an attack is shown as a dark orange arrow coming from the left and being detected and stopped at the network firewall

where the incoming invalid request (potential attack) is shown as a dark orange arrow. Of course, your architecture may include other types of application firewalls, load balancing and clustered servers in a 3-tier arrangement:

Schematic diagram showing, from left to right, a border router, network firewall, application firewall, load balancer, web servers (only one shown), application servers (only one shown) and database servers (only one shown) - an attack is shown as a dark orange arrow coming from the left and being detected and stopped at the network firewall

Even this more complex architecture doesn't show other servers and network devices that may exist such as network storage, authentication servers, intrusion detection systems (IDS), backup devices, the internal network, failover/standby systems, etc. But unless these systems log appropriately and these logs are incorporated into real-time alerting and monitoring systems, we might be none the wiser that someone (an "attacker") is having a go.

In many cases it may be better to let the request pass through the intermediate control points so that application itself can assess the request and, probably reject the request. But this means the application can record and report on this, and possibly use this information to combine with other anomalous requests.

Schematic diagram showing, from left to right, a border router, network firewall and multi-function server (with the web site, application code and database) - an attack is shown as a dark orange arrow coming from the left and being detected and stopped at the application server(s) Schematic diagram showing, from left to right, a border router, network firewall, application firewall, load balancer, web servers (only one shown), application servers (only one shown) and database servers (only one shown) - an attack is shown as a dark orange arrow coming from the left and being detected and stopped at the application server(s)

Requests that could harm the web or application servers should of course be restricted earlier than this. But in the example of source constraints, it is better to ensure as much information about the source and content of the request is captured. A network firewall is not the best device for this.

The method implemented will depend upon what logging and correlating facilities are in place. If you have a central analysis server such as a Security Information and Event Management (SIEM), this may also be an option for controlling the blocking action with a number of possible prevention points.

Schematic diagram showing, from left to right, a border router, network firewall, application firewall, load balancer, web servers (only one shown), application servers (only one shown) and database servers (only one shown) but with the addition of a Security Information and Event Management (SIEM) - an attack is shown as a dark orange arrow coming from the left and being detected by the SIEM and stopped at a any of the network devices and servers

The other problem with moving security controls away from the application is that there are potentially more configuration settings to implement, and the application itself may not be able to detect if these are in place. If the application has knowledge of attacks (by its own monitoring or via a SIEM), it may be able to be more strict with subsequent requests from the same source, or adjust its general security posture to a more defensive condition.

Posted on: 12 March 2010 at 19:57 hrs

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

02 March 2010

Security and Design

Last week I visited the London Design Museum on South Bank. One of the current exhibitions is about Dieter Rams—not someone I was aware of previously—who is head of design at Braun, the German consumer electronics manufacturer. The exhibition included scores of examples of products he has designed over 40 years; with many on loan from Braun's own archives.

Photograph of the exhibition signage at the Design Museum saying 'Less and More: The Design Ethos of Dieter Rams'

Ten Principles of Good Design

But Rams' ten most important principles of good design caught my eye since it seemed they might apply more widely. I wondered how they might be applied to good security. Of course the ten most important security principles would actually be something else, but let's just look at Rams' ones.

Good design security is innovative

Technological developments offer new opportunities for innovative security. Security practitioners must innovate to meet new threats.

Good design security makes a product useful

Interesting in the security context. I believe that good usability includes good security and vice versa. Good security won't always make a web application useful, but equally good design can never truly make up for fundamental shortcomings of a product. Good security should enhance the application, not detract from it.

Good design security is aesthetic

I don't expect aesthetic quality to be mentioned any time soon in the ISO 27000 series of standards, but if we can achieve beauty, that should be preferred. For example, ugliness in user interfaces inevitably introduces errors in data selection and entry, and these may have a security impact.

Good design security makes a product understandable

Self-explanatory security? Yes, the inclusion of security measures should aid the user's understanding. Security measures should complement the software and make sense.

Good design security is unobtrusive

Security should not get in the way of the other functionality and where it is visible, its reason and method of use should be obvious.

Good design security is honest

Cut out the fear, uncertainty and doubt (FUD). For example, don't include claims about security (and privacy) that are not true or cannot be substantiated.

Good design security is long-lasting

Repeated changes to software are prone to introducing faults and should require a carefully controlled change management processes. By getting it right first, and not having to change security measures later, this makes better security.

Good design security is thorough down to the last detail

Building security in at an early stage by assessing the risks and requirements reduces the chance of having to make arbitrary decisions later or security implementation being left to chance.

Good design security is environmentally friendly

This one is harder, but perhaps good security uses resources more efficiently? It is certainly more expensive to fix faults later, so there could be an environmental benefit.

Good design security is as little design as possible

Purity? Simplicity? Architectural and programming code complexity leads to faults that may be security vulnerabilities. It is also difficult to maintain. Yes, keep it as simple as possible to achieve the security requirements.

Maybe in time we'll have security celebrities who adorn software packaging and interfaces with their signatures, like sportsman on clothing or chefs on saucepans. I don't think Dieter Rams would ever want his signature on one of his designs—they are enough of an inspiration without adding un-necessary branding.

Top Ten Most Critical Web Application Security Risks

There's a different "ten" being presented and discussed at OWASP London this Thursday: the OWASP Top Ten 2010 RC1. Web application developers should find the new document and associated cheat sheets a great help but it's very important for organisation subject to Payment Card Industry Data Security Standard (PCIDSS). As usual all meetings are free and open to anyone, but prior registration is required. The meetings are very popular, so register now if you haven't already.

Posted on: 02 March 2010 at 09:37 hrs

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

12 January 2010

OWASP London - This Thursday

The next Open Web Application Security Project (OWASP) London meeting is this week.

Photograph of a metal grid mesh

The London chapter meeting is on Thursday 14 January 2010 in EC1. Everyone is welcome, but you need to register first (free).

There will be talks on Top Ten Deployment Mistakes That Render SSL Useless by Ivan Ristić and Using Selenium to Hold State for Web Application Penetration Testing by Yiannis Pavlosoglou, who recently joined the OWASP Global Industry Committee.

Unfortunately I am unable to attend the meeting but hope to read the presentations afterwards.

Posted on: 12 January 2010 at 09:46 hrs

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

20 November 2009

Layered Communications and the Web Site Concentrator

Examples of content aggregation often refer to the use of web services and XML data such as RSS feeds. But today's world of web 2.0 in creating more and more data in a wide variety of formats including JSON (JavaScript Object Notation); and web applications are being used as a concentrator to combine these together.

With the growth of layered communications, multiple communication channels such as text, video and audio are merged into one event. If the content is recorded it can be republished via a web site. But what are the specific security risks of this?

Web services and XML data can include invalid or malicious data. The format/schema may be incorrect. But with the increase in layered communications, content from many different devices in many media may need to be aggregated into a single resource; and these often don't have any formal syntactical structure. The data might even include active content such as embedded rich applications.

Diagram showing six data feeds (voice, text, photograph, application video and ?/other) contributing to the output from a web application

If these need to be stored and replayed such content at a later date, how might they affect a web page? The content could contain, or link to, malicious content that steals user data such as session cookies, modifies the page's content or installs malware onto user's computers.

  • Identify all the data streams.
  • Determine their formats and encoding where appropriate.
  • Ruthlessly limit what active (script) content is allowed and what ability it has to interact with the parent web site and its domain.
  • Analyse the data streams to validate they contain what is intended and scan for malware.
  • Sanitise content where applicable.
  • Limit file size/length/number of nodes.
  • Avoid merging trusted and untrusted content in data fields.
  • Encode the output correctly for your own application.
  • Monitor activity and look out for unusual events.

And beware embedding rich internet applications (RIAs) such as Adobe Flash or Microsoft Silverlight, which may be doing this aggregation themselves.

After all, you don't want your web site to be a concentrator multiplexing malware.

Posted on: 20 November 2009 at 12:20 hrs

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

25 October 2009

From Whiteboard to Web Application

Sometimes finding all the web applications in an organisation can be the difficult part in trying to assess what risks exist.

Transport for London don't just have web sites and, I suspect, an intranet. They have been gradually moving from whiteboards for live underground travel news at tube stations:

Photograph of a transport information board at Great Portland Street station where the information is provided on magnetic tiles and by hand written wipe-dry pens

And now have electronic versions:

Photograph of a transport information board at Farringdon station where the information is provided on an LCD or plasma display

I don't know what technology is being used here, but other information boards have been seen to display web browser error messages leaking network information:

Photograph of a transport information display showing an 'address not found' error message from Firefox

But, what about elsewhere? I saw this on the live electronic advertisement boards at Bond Street station this weekend:

Photograph of an advertisement display board at Bond Street station elevators showing the words 'System Name' followed by a code and what looks like an IP address, written vertically up the portrait-orientated unit

Sorry it's a bit blurred, but I was going up the escalator at the time. Several, but not all the displays had their system names shown rather than an advertisement. It certainly looks like an IP address, but is there a web application inside? I've previously highlighted other information systems and displays that seem to be IP-enabled.

An investigation of your network, examining what is listening on which ports, and correlating this with the actual network traffic, might reveal more web applications than you thought.

Posted on: 25 October 2009 at 18:46 hrs

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

16 October 2009

Warning: Punctuation Marks Can Damage Your Web Site

It seems a missing full stop brought down every web site hosted on a domain ending with .se (the top-level domain for Sweden) on Monday evening.

Partial picture of Table 4/T.50, the basic 7-bit code table, from the ITU-T Recommendation T.50

The .SE registry had apparently performed an incorrect software update but actually a script (program written by a human) had failed to add a terminating full stop (.) to the DNS records in the .se zone. Tested? I guess not.

It reminded me of Google's mishap in May when it flagged every site as potentially harmful by simply adding an extra forward slash (/) character to a file.

And, simple punctuation mistakes can invalidate the HTML of your web page, or stop your application's scripts from running. In July Microsoft created a security flaw in Windows by the addition of an extra ampersand (&) character.

Tim Berners-Lee is still wishing he hadn't put two forward slashes in every URL.

The mighty power of a punctuation mark.

Posted on: 16 October 2009 at 15:24 hrs

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

More Entries

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

Requested by 184.73.52.98 on Friday, 25 April 2014 at 03:25 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