Could DLP have prevented BoE Bookend disclosure?

Robert Broxup

    The Bank of England accidentally sent information about a research project to a journalist at The Guardian to identify the financial risk of the United Kingdom leaving the European Union. Could an effective Data Loss Prevention (DLP) strategy have stopped this breach?

    DLP is about ensuring users do not send confidential or classified information outside the corporate network, driven by threats from inside businesses and legal duties to protect personal data. The key questions asked are:

    • Where is the data located?
    • Who has access to the data?
    • How is the data being used?
    • How can we prevent it from being lost or stolen?

    Nobody has suggested that someone intentionally leaked Project Bookend details to the media, nor that the breach was in any way malevolent. However, with the right policies and systems, accidental and malicious data losses are preventable.

    An effective DLP solution would include:

    • Monitoring specific files or project directories identified as confidential
    • Network and endpoint monitoring to track access, data transfer or writing files to USB devices
    • Detection of uploads to social media sites or to file storage services such as Dropbox
    • Specific profiling of data defined such as bank account numbers, National Insurance numbers, insurance policy numbers, postcodes or credit card numbers
    • Networks and endpoint monitoring to track data transfers of files containing profiled data structures, allowing for cases where someone adds confidential data to other files which would not usually attract attention
    • Integration with email services and other network protocols to intercept and block the transmission of data where attachments contain content that matches the defined profile of confidential data

    An attempt to send the files externally would trigger interception of the email and prevent it from being transmitted; essentially, it would be a quarantine of the entire email along with any attachments for further investigation by an information security analyst.

    Managing exponential growth of data

    Robert Broxup

    Data storage is available at a low cost, and extending storage space is an easy solution to deal with data growth. However, how often do you take this action only to find out three months later that the same problem has returned and more space is required? Increasing capacity is part of the solution and needs consideration as part of a long-term data storage strategy and retention policies.

    The notion that data storage is cheap is very subjective and depends on many different factors beyond the price of disks. The acronym RAID, which initially meant ‘Redundant Array of Inexpensive Disks’, is somewhat misleading in that it conveys the message that storage is cheap without considering many other factors including:

    • The costs of other hardware requirements
    • The costs of physical space in data centres
    • Employment costs
    • Maintenance
    • Ongoing support

    The overall cost of data storage is more important relative to the value of the stored data. RAID more commonly means ‘Redundant Array of Independent Disks’, which is more appropriate.

    Parkinson’s Law states that one’s work will expand to fill the time available to complete it. The same principle applies to space: a requirement for storage will increase until it reaches maximum capacity. Buying a second filing cabinet has the long-term effect of doubling the number of documents stored. Notice at home that the same applies to cupboards, shelves and coat hooks, and how often a spare bedroom fills up over time. A corollary of Parkinson’s Law relating to the growth of data is that stored electronic data will expand to fill whatever storage space is available for systems to use.

    The key areas to be fully explored before investing in new hardware are:

    • Housekeeping – cleanup of historical data storage where appropriate to reduce strain on systems
    • Ongoing policy – decisions on what data is stored and for how long
    • Capacity planning – projecting future storage requirements and proactively planning any storage expansion

    Reducing the need for storage has an added benefit to the environment of reducing energy consumption.

    We are committed to saving energy and resources. We offer our clients a challenge to use housekeeping, policy implementation and capacity planning to reduce storage requirements and to contribute a portion of any financial savings from the storage budget to their favourite charity.

    Inadequate SAM during Mergers & Acquisitions

    Robert Broxup

    Buying a company or merging to create a new company, without understanding the current software licensing position, can lead to significant and avoidable costs. Financial and legal due diligence is standard practice in mergers and acquisitions, but IT implications are seldom given the same required attention. Software Asset Management (SAM) is a recurring blind spot in IT due diligence, often leading to licensing exposure and unforeseen integration costs. Unplanned and unnecessary IT costs can significantly impact on the overall economic viability of the deal. IT due diligence will eventually become a standard part of the mergers and acquisitions process.

    In the post-merger environment, with significant changes taking place such as role changes, redundancies, new computer systems and business processes, the addition of new geographical locations and new legal jurisdictions, this is likely a time when compliance is low. Therefore it is not surprising that announcements of mergers and acquisitions are an impetus for software licence audits by vendors.

    Key questions to ask include:

    • What is the current position with software licensing across both companies?
    • What is the software licence shortfall value of the target company?
    • Has the software licence shortfall cost been factored into the sale price of the business?
    • How mature are SAM processes in both companies?
    • What will the software licence position look like after two companies have merged?
    • How much will it cost to purchase new licences?
    • Who owns the software licences?
    • Can the software licences be reallocated to a new organisation?
    • Are existing licences transferable under the terms of the original agreement—and are they valid in the new legal entity?
    • What opportunities are available to renegotiate licences?

    Important points to remember are:

    • Proactive dialogue with software vendors during the merger or acquisition process will result in increased bargaining power and strengthen supplier relationships
    • Reactive dialogue in response to a software vendor licence audit puts the licensee in a relatively weak position

    IT due diligence must become non-negotiable in any acquisition strategy. As software landscapes become more complex and licensing models evolve, asset visibility is not optional, it is essential.

    Improving Software Purchasing Decisions

    Robert Broxup

    Vendor software solutions usually have configurable settings to work in a particular environment. However, businesses must avoid solutions that require extensive custom development simply to meet baseline expectations. Without understanding the required level of configuration or customisation, costs for the new solution can quickly skyrocket. Investigate the solution more thoroughly before making a buying decision. Using the system ‘out of the box’ should be a viable option.

    Here are some examples, but these will vary depending on the type of system:

    • Identify and Access Management – does the solution have a built-in option to integrate with Active Directory or other directory services? Given the level of Active Directory usage throughout the world, this should be the case for this genre of software. Configuring the system to know which domain to look at is expected. However, it would be a disappointment to purchase the solution and then need to pay extra for the development of an integration module.
    • Support packages used to fix products – bundling support with software is common, but selling consultancy just to make the software function properly reflects poor product maturity. Sadly, offering consultancy to make the software operational and fit for purpose is often a fact of life in the IT sector. The consultancy services could quickly become more expensive than a “built in-house” solution.
    • Existing integration modules – what systems does the solution already integrate with as standard out of the box?
    • Identify and assess all customisation requirements upfront – a viable solution should be functional out of the box. If there are special requirements that no other organisation has, then the software may need tailoring. Assess whether the level of customisation justifies choosing the solution at all.

    If the product needs modifications, you should thoroughly consider if it is the right choice and investigate other options.