Minimising the risks of Cyberspying your organisation

When we hear the term ‘spying’ or ‘espionage’, we immediately think of the CIA and the KGB, or of James Bond. The term ‘cyberspying’ probably brings to mind equally strong images of Robert Redford in Sneakers, or Angelina Jolie in her earlier role as ‘Acid Burn’ in Hackers, or the real-life exploits of cracker-turned-consultant Kevin Mitnick. However, industrial cyber espionage is often far more mundane, and far more widespread (and hence more dangerous) then the widely-held perceptions of a few highly brilliant individuals going after high-value national assets. The key to success for many a company lies in information that only that particular company (in the persons of its designated officials) knows. For example, KFC’s “finger lickin’ good” recipe of “11 secret herbs and spices”, or Coca-Cola’s Classic Coke formulation, are worth millions, even billions, on an annual basis. Yes, they can be patented, but patents expire and afterwards, any other company can use the same recipes and formulations in their own competing products. Hence, both KFC and Coca-Cola opted not to have legal procedural protection, instead relying on keeping these data known only to themselves. Such data are called “trade secrets”. Nor are trade secrets limited to product formulations. The WIPO defines them, essentially, as just about any kind of information that confers a competitive advantage. Customer information, results of privately-conducted studies, R&D, advanced techniques and processes – any and all of these could be your organisation’s trade secrets. While trade secrets can be protected by law, certain criteria (which differ from country to country) have to be fulfilled – chief amongst which is that reasonable care must be taken to ensure that they remain secret. This includes ensuring that NDAs are signed when shared with 3rd parties, only a few people within the company know the trade secrets – and that they know it is secret, and it also includes securing the information systems which have access to these trade secrets. There is a lot of money to be made from industrial espionage. National governments all over the world are now conducting cyberspying for the benefit of their domestic industries – and to further pursue national objectives, of course. McAfee, a well-known antivirus software company, estimates that a single operation (Operation Shady RAT) may have cost billions in lost revenues and trade secrets. There are very high incentives for ‘black hat’ hackers to crack your information systems and gain access to your trade secrets. As always, these crackers and hackers get their hands on these industrial trade secrets by exploiting vulnerabilities to penetrate your security perimeter. And don’t think that just because you’re a small company, you will too insignificant to target. Over 80% of small businesses in the UK had their IT systems breached last year – and it’s not an exclusively First World problem either. Even in Ghana, SMEs are being warned about cybercrimes, including cyber espionage. So how can you mitigate against these potential threats? The best move, of course, is probably not to store your trade secrets in cyberspace. If there is no need for computer access to your trade secrets, then convert them into a non-digital physical format (microfilm, engraved on a pewter plate, acid-free paper etc.) and store them in a vault (or vaults). However, this is probably infeasible for most organisations, or render these secrets commercially useless. Having – and enforcing – a proper vulnerability management policy will cut down significantly on the attack surface your information systems present to crackers. Other security policies, such as appropriate encryption both in transit and on the storage media themselves, as well as strong passphrases, or physical and network isolation of the computer systems containing the trade secrets, can also be implemented in addition to the other usual vulnerability mitigation steps.

Posted on: 23 May 2013 | 9:45 am

Locking down your servers and workstations

In this day of cloud computing and SaaS (Software as a Service), many companies are making the choice to outsource their storage and email needs (amongst others) to a 3rd-party datacentre or service provider. But there are cogent reasons for maintaining in-house servers; whether for more control over your data and trade secrets, or for cost optimisation, your organisation might have decided to take the path of maintaining your own authentication, file, email, IM, videoconferencing or VOIP server solutions.   If this is the direction that you have chosen to go, then you should be aware of the implications of this decision. Aside from the issues of redundancies, backups, uptime and all the other criteria usually spelled out in SLAs, you will be responsible for patching, updating and upgrading your server solutions, as well as ensuring that best practices are followed when securing and hardening your servers (and along the way, your workstations also) against attacks.   In this post, we are concentrating on using vulnerability management to enforce the principle of least privilege, as well as the reduction of attack surfaces on your servers. Regardless of whether you’re using Microsoft’s server solutions, or you have decided to deploy commercial Linux (e.g. Red Hat, Oracle, SUSE etc.), or go the UNIX route, you want to ensure that your servers (which, after all, are the largest part of your organisation’s IT infrastructure, and run business-critical applications) present as small a target as possible to would-be crackers.   The most common of all server hardening principles (and there are many of them), regardless of whichever server solution, is to adhere to the ‘one role, one server’ rule. That is to say, if you need a file server, then make sure a particular installation of Windows Server (or RHEL) has all the necessary capabilities and permissions for serving files and no more. Similarly, if you need a database server, ensure that all other permissions and server capabilities (e.g. web server, print server, DNS server etc.) are either uninstalled or disabled. The reasoning is simple; if someone managed to subvert your database server’s security measures, they do not then also have access to your file server, thus reducing the impact of the breach.   In the past, this was somewhat impractical; if you needed many different types of servers, you would need to buy hardware for each one. Now, with hardware virtualisation and hypervisor technologies, you can deploy all these servers running at full speed, but using the same physical hardware. This still keeps each role distinct in its own VM, and maintains separate ACLs and permissions for each server. In fact, Microsoft’s Windows Server 2012 has Server Core as its preferred installation method – install Server Core, install the specific server role you need, and that’s it.   Even if you went down the route of using virtualisation to separate your servers, you still need to run through the vulnerability management steps (see earlier post), because there are still many services/daemons running on your servers you might not know about – at least when using a commercial Linux distro. The situation is not much better on Windows, where even the workstation OSes run many services automatically by default.   And there’s no slacking off, either – you may have hardened your servers when initially installed, but have you since then kept them updated and patched? Do you know what else has been installed on your servers by some other sysadmin? Have there been any configuration changes done while you were on vacation? Vulnerability management is an on-going process.

Posted on: 15 May 2013 | 8:21 am

'Smart' consumer electronics security

Most people are aware of the needs of IT security in the office, especially in dealing with PCs, smartphones and tablets. A smaller segment of the population (including, we hope, our customers and readers) are more clued-in when it comes to IT security as it affects industrial embedded devices, such as SCADA systems. But much fewer people stop and consider the security impact that ‘smart’ consumer-grade electronics poses to your home network, and quite possibly to your office as well. In this post, we want to separate out the facts from the FUD hype, and bring the matter to your attention.   The notion of “digital convergence”, or that of being able to gain access to your electronic devices and data from anywhere, is not a new one. As far back as 2000 (or even earlier), then-CEO of Microsoft Bill Gates projected forward a time when you would be able to watch movies being streamed from your computer down in your den in your bedroom. Today, of course, this is a reality in many homes. The DLNA (Digital Living Network Alliance®) has brought this about, through an array of TVs, set-top boxes, wireless media players, routers and PCs. You can buy Skype-enabled wireless cameras that attach to your TV, turning it into a videoconferencing platform – and many businesses do exactly that.   But the larger goal of accessing anything anywhere goes further than this. Samsung, for instance, introduced ‘smart’ washing machines early last year in CES 2012. Through a smartphone app, you can monitor and even control your washing cycle. If you think this is farfetched, your oven, refrigerator, air-conditioner, and even your electricity meter can be ‘Net-enabled, ostensibly to provide you with far greater control over your household chores and energy consumption. And with cars also coming with Bluetooth and WiFi connections, there could come a time when your car notifies your house that you are about 15 minutes out, at which point your oven (which has been keeping your marinated chicken refrigerated) starts cooking and your air-cond turns on, so you walk into a cool house with a hot dinner waiting for you.   All this convenience comes at a price. Every Internet-connected appliance/smart device you have is another potential source of vulnerabilities to your home network – and if you VPN or use your work intranet, also threatens your office network. This is because most smart devices run a variant of embedded Linux or Android, or possibly Windows CE/8 RT – OSes that crackers are very familiar with. But even those than run proprietary systems are vulnerable. And while you may think locking down your router and installing a hardware firewall is sufficient protection, that still does not prevent crackers from gaining access to your appliances, and from there, your computers – and the data they contain. For example, smart TVs and media players often allow you to upgrade their firmware – and possibly infecting them with malware at the same time.   How bad is the situation? Well, Samsung, having created PCs and some of the most popular Android devices, presumably knows about network security. And yet, a researcher has claimed that ALL Samsung smart devices have the same basic vulnerabilities that allowed him to gain root access to them as well as all connected drives. Smart meter vulnerabilities have been known for years, and smart grid security has been described as a ‘circus’ by those specialising in the field. Even the medical profession is sitting up and taking notice of IT security in embedded devices – probably because you don’t want somebody crashing the life-support system.   Most egregious of all, the very vendors who hawk home monitoring and security systems (CCTVs, IR cameras, motion sensors etc.) are themselves vulnerable to the same kind of crackers. These systems, even when not connected to the Internet, communicate with each other… in the clear, without encryption.   So if you have any of these ‘smart’ devices, it may be time for you to think about your network security in light of what you now know.

Posted on: 29 April 2013 | 9:34 am

What is SQL Injection

In a previous post, we highlighted some of the potential types of vulnerabilities due to ‘bad’ input. This post concentrates on one of these types, which is known as ‘SQL Injection’. This vulnerability class is one of the most common ones in WWW applications, despite the fact that web programmers should know better. It is also one of the most potentially devastating, and one of the hardest to guard against.   It is worthwhile, before diving into the vulnerability itself, to put it in its proper context. Today’s World Wide Web, unlike its beginnings, is no longer a simple static display of text and images. Almost all the wonderful and interactive uses of the Web (as we understand it today) are powered by databases. Be it social media like LinkedIn, WordPress and Facebook, email services like Hotmail/Outlook.com and Gmail, online shops like The Book Depository and Amazon.com, or even payment processors like PayPal, the backend (or the core which is the source of the usefulness) of a modern web service is a (usually relational) database.   A database is commonly made out of separate pieces of information pertaining to a particular ‘thing’ (e.g. Name, Date Of Birth, Address) called ‘field’s, which are then assembled into ‘record’s. Each record contains information on a single ‘thing’ (be it a Customer, Inventory Item or Transaction), and a collection of similar records (of the same type of ‘thing’) is called a ‘table’. Relational databases require that each table of similar records have at least one field unique to each record, or ‘primary key’. This primary key can then be placed in another table (where it is then called a ‘foreign key’). The two tables are then related to each other through this ‘key’; hence the name relational database.   The power of a relational database lies in its ability to construct ‘queries’, or to return results based on certain criteria. For example, if the Transaction table contains all the sales made, you can provide a specific customer, details of all the sales made by him, by selecting all transactions where the Customer ID is his. Or, you could present all his sales in a particular date range. By using a programming language specifically meant for use on databases, and by manipulating the database in various ways, you come up with today’s widely varying Web applications.   Structured Query Language (SQL for short) is a 4th-generation database programming language. It is specifically designed to create, modify and generally work with databases. When you register for a new account, click an email to read it, or comment on a blog post, you are actually creating a new record, accessing an existing record, or adding to a record. The website may present you with a pretty screen and nicely designed buttons, but at the end of the day, all of it gets translated into SQL instructions (‘queries’).   This is where SQL injections come in. Obviously, the websites have to allow for user input; otherwise, how can they get your details or know what you want to do? However, because the end result is an SQL query, it is possible for a cracker to ‘inject’ several SQL commands into the space originally intended for filling in your name (or whatever else). This potentially allows the cracker to do anything he wanted with that database. If the database held credit card details, this can include him retrieving all these details.   This usually happens when the web programmer naively (and directly) accepts the user’s input. A poor programmer will have the website build the SQL instruction dynamically, using what the user provided. And if the user provided additional SQL commands instead, then that’s what gets handed over to – and executed by - the SQL server in the backend.   How bad is this class of vulnerabilities? It can be potentially very severe. Some SQL server software allows you to run OS commands from within SQL queries; it takes no imagination to see how horrifying this is. A cracker having total access to your customers’ financial information is also cause for grave concern. Guarding against SQL injections is therefore of critical importance to any web developer.

Posted on: 2 April 2013 | 5:17 am