Month: January 2014

Contractor Security Risk Management Advice

If you want to keep your network as secure as possible, don’t let anyone connect to it. That is not particularly practical advice of course. Employees must be allowed access, and when devices are allowed to connect to a network, risk is introduced. There will always be some level of risk involved unless a network is entirely closed, but what about allowing contractors, partners and suppliers to connect? Collaboration is important. If you manage access, there can be great rewards to be gained. However, get contractor security risk management wrong and it could spell disaster.

Contractor security risk management: A choice between access and security

Many companies face a choice. They can opt for productivity and practicality, and accept a reasonably high security risk, or they can make changes to address risk at the expense of productivity. Take U.S. bank Wachovia for example. The bank was one of the largest in the United States, yet during the great recession it took a merger with Wells Fargo to keep it afloat.

How did two banks operating two separate email systems manage to collaborate securely? Wells Fargo used Microsoft Outlook for email, while Wachovia had chosen Lotus Notes. It was possible to send an email between the two, but end users could not send encrypted emails. The solution was to move Wachovia over to Outlook, but this was not a quick and simple a process.

The banks decided changing to one system would cause too many problems and instead they opted to just send unencrypted email. This involved some risk, but it was deemed to be preferable to the nightmare of migrating an entire company over to the new system. They ran Lotus Notes and Outlook together, insecurely, for a number of years. Productivity was deemed to be more important than security in this instance. The decision came down to a simple case of risk over reward, or cost versus benefit.

When it comes to contractor security risk management, you may adopt a similar approach. If the risk is higher than the rewards, then address the risk. If the rewards are higher and the risk fairly low, go with the rewards. To make that decision, you need to have figures. Rewards are relatively easy to calculate in terms of increased profits. Risk may be a little harder to translate into a figure.

Assign a value to risk when developing contractor security risk management strategies

Rewards may be increases in profit, products shipped, reduction in time to market, reduction in wasted hours, or even a fall in support calls. Productivity is defined as output per employee, multiplied by the number of employees. A monetary value is therefore relatively easy to assign.

When developing your contractor security risk management strategies, you must be able to do the same with risk. You will need to determine your output and your input, and for that you will need to follow the COBIT 5 governance framework.

Under COBIT 5, you must maintain a risk profile. Each type of data kept by your company must be assigned a score. The score is determined by the impact loss, theft, or corruption of that data would have on the business. It must be possible to quantify risk in order for decisions to be made as part of the contractor security risk management process.

Once you have identified the risks, and assigned each risk a value, you can then put those inputs into your contractor security risk management calculations.

Reducing risk when collaborating with contractors and suppliers

You may require contractors to have access to a system as this will save time and money. A good example is a project with multiple subcontractors; a construction project for example. If each subcontractor can enter their own data, this is often preferable, as it reduces the possibility of errors being introduced. Some software is designed with collaboration in mind; Lotus Notes or Oracle Primavera for example – the latter being specifically developed for use with large construction projects. However, before access to any system is allowed, risks must be managed. That can be achieved by:

Providing training

Explain the security risks and how they can be reduced or mitigated. Issue best practice guidelines, such as physically securing devices, password management policies, phishing and hacking risk management, connection of USB drives, and Smartphone use etc.

Scanning all devices connecting to a network

It is no longer necessary to give contractors and suppliers access to shared network drives or your LAN in many cases. They could use desktop or mobile apps, and could connect to cloud services used by your company. If LAN access is required, then they must install the necessary security software that you use. Anti-virus, anti-malware, Anti-spam, and web filtering solutions will be required. Their devices must also be regularly scanned for infections.

Blocking social media access

Social media website use introduces risk. Corporate computers, which are connected to the LAN, should not be used to access social media websites. Personal devices can be used for that instead. Internet use on LAN-connected devices must be limited to reduce the risk of drive-by attacks and accidental downloading of malware. A web filter should be employed to manage the websites that can be visited.

Conducting security audits

You will no doubt already be conducting audit on billing, and also the quality of the services provided, but also make sure you conduct security audits. You need to make sure that your contractors are not exposing you to unnecessary risk and are following the best practice guidelines that you have issued.

How the Target Hack Would have been Worthless with Encrypted Credit Cards

Encrypted credit cards? Don´t they already exist?

Encrypted credit cards have been around for a long time now – or, at least, credit cards with a limited amount of encryption. The magnetic strip on the back of each credit card is encrypted, and so is some of the data in the more recent chip-and-PIN cards, but basically the security offered by most encrypted credit cards is, well, basic.

When you go shopping in a store like, let´s say Target, the retailer provides an electronic terminal for you to scan “encrypted” credit cards. The terminal sends your card´s identifying data to the credit card company´s servers to verify that you have the funds to pay for your purchases.

Although the electronic transfer of information is encrypted in transit and at rest, there is a weak point in the process during which the data is decrypted into clear text so that it can be read by the payment processing software. In Target´s case it was the point of sale (POS) electronic terminal where the weak point was located.

The Target hack was on a massive scale

Hackers used the weak spot in Target´s POS electronic terminals to steal the details of 110 million credit and debit cards. Not just the credit card numbers were taken, but their PIN numbers and the card holder´s address, email and phone number – suggesting that Target´s customer database was also hacked (because encrypted credit cards do not have your email address on the magnetic strip).

Initially the retail giant tried to cover-up the hack, but as shoppers started reporting unauthorized purchases on their credit accounts, Target had to come clean and admit to the data breach. As a result, the lawsuits are flying in, Congress called the company negligent and attorney generals in every state in the country are looking into the matter.

The damage to Target – both financially and in terms of lost reputation – will be billions of dollars

Yet the hack could have been worthless

Had the retail industry adopted properly secure encrypted credit cards, the hack of Target´s database would have been worthless. Properly secure encrypted credit cards work not by storing the credit card number and PIN on the magnetic strip, but by storing a random encrypted number and a public key.

When a purchase is made at a store like, let´s say Target, the retailer does not need the credit card number or PIN, just an authorization code so that the card can be charged. So, when the credit card is used, the random encrypted number and card holder´s public key is transmitted to the credit card issuer. The credit card issuer sends back an authorization code that just the credit card would be able to read.

This “PKI encryption” at the point of sale would mean that any hacked credit card details would be worthless to the hacker. It would cost billions of dollars to introduce a system for properly secure encrypted credit cards to be used in the retail industry, and there seems to be no consensus between banks, retailers, and credit card issuers on what standards should be used.

Google already making strides towards genuinely secure payments

Google has already addressed the problem of genuinely secure payments with the introduction of its Digital Wallet. The Digital Wallet works by isolating credit and debit card data and processing it outside of the Android operating system in a chip they called the Secure Element (SE).

Google´s plan of keeping credit card data out of the reach of malware running in the operating system has really taken off. Many companies are in a battle to come out on top in the lucrative market for credit card fees. Because of a lack of consensus, few manufacturers are adding the SE chip to mobile devices or the near-field communications chips needed to radio encrypted data from encrypted credit cards to the POS terminals.

Because of the lack of consensus between banks, retailers and credit card issuers, and a lack of knowledge about which way encrypted credit cards are headed – if at all – many more retail companies are likely to experience a similar attack to that witnessed by Target.