10 keys to successful patch management

The recent spate of Java vulnerabilities has required a number of large vendors to react almost instantly to optimize security levels. But as good as these reactions are, organisations urgently need to apply insightful strategic thinking to ensure that security updates are reaching the entire organisation’s IT estate.

CentraStage analyzed anonymous hardware and software data (including thousands of PCs and servers in 6,000 organisations across public sector establishments currently running our solution) and found that 40 percent of servers and workstations are missing security patches. In addition, six vendors — Microsoft, Adobe, Mozilla, Apple, Oracle, and Google — together released 257 security bulletins/advisories fixing 1,521 vulnerabilities in 2011. In 2010, these vendors fixed 1,458 vulnerabilities, demonstrating the extent of the issue as well as the numbers of bulletins we annually face.


With more and more organizations supporting remote working, the challenge isn’t just to implement patches as they are released, but to be fully confident that devices have been updated and are thus continuously safeguarded. So what areas should IT experts tick off the list for a successful patch management implementation?

1: Ensure transparency


At the heart, asset discovery is essential. If you don’t know what you’ve got, you don’t know the extent of the problem you may have. If you do nothing else, make sure you know where your IT assets are; this is a quick gain that will put your house in order.

Once the estate is established, you need to have real-time visibility of the assets you support. With the urgency in which we need to manage patches, the first secret is to not only have full awareness of the estate but instantly know the health of it too.

2: Don’t just look at the security

Knowing the whereabouts and health of the IT estate is paramount, as it provides the intelligence for ensuring its security. A study of public sector CIOs in December 2012 found that 87% of respondents were either concerned or very concerned about the risks associated with IT security breaches. In addition to security, keep an eye on securing IP, as it can be used in protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host.

3: Define your patch nirvana

While the audit and assessment element of patch management will help identify systems that are out of compliance with your guidelines, you should also work to reduce noncompliance. Start by creating a baseline — a standard you want the entire estate to comply with. Once complete, it’s easier to bring controls in line to ensure that newly deployed and rebuilt systems are up to spec with regard to patch levels.

4: Face the facts

You must know which security issues and software updates are relevant to your environment. Further analysis of our data showed that 50 percent of PCs and laptops are still running Windows XP, and 32 percent of devices are more than four years old.

Beyond patch management and the protection against vulnerabilities and exploits that by now must have caught the attention of IT leaders globally is the preparation and planning for end-of-life Windows XP support. If you do not replace, there is no way to safeguard. If you do replace, this has implications on expenditure. Make sure that you have a realistic view of patch management and its limitations, but also ask whether the discipline of patch management indirectly ensures the infrastructure and IT estate is viable from support and budget perspectives.

5: Do it your way with software policies

You can customise policies targeted at filters or groups at the account or profile level. The filter targets can be either the default filters provided within your account or any custom filters you have previously defined. The secret here is to define custom filters or groups to identify devices with specific criteria. One or more of these filters can be associated with a policy to target those devices.

This goes back to your baseline creation. Set the policies from the outset and customisation will be a simple step forward.

6: Get the timing right

Why wouldn’t you implement a patch management update as soon as you can? With baseline mechanisms in place, there’s no need to delay. However, you should consider the time of day for updates by policy — what time will have the least impact on day-to-day business? The ideal timing for updating patches should follow any rollout best practice. Consider the day of the week, the impact on the business if something doesn’t go smoothly, and whether there is sufficient time and resources to rectify if necessary. If your IT management solution is on-premise rather than cloud- based, you might have to take responsibility of scale and load of the update.

7: Audit first — is it too broken to be fixed?

Gaining visibility of devices that are vulnerable is crucial, but so is analysing the overall health of each device. Ensure that all devices are audited prior to rolling out patches or patch policies. There could be a more urgent matter requiring attention before the device can be brought in line.

8: Keep it simple

We are led to believe that the bigger the enterprise estate, the more complex the management. But in most cases, solutions are easily scalable. The issue comes with usability. As complexity increases (and in some cases, the number of solutions and providers also grows), the technology team is used more and more to ensure the estate is kept up to date. Keep usability as simple as possible. There are solutions that do not even require a technically skilled person to ensure the estate is kept up to date quickly and easily.

9: Consider automated solutions

Often, patch management is a distress purchase because vulnerabilities such the ones we’ve seen recently place patch management in a crisis management budget and not an ongoing IT budget. Of course, this has financial implications. Some enterprise IT management solutions may save you money by providing tools that automatically audit and monitor. If automation is behind the scenes, it doesn’t interrupt the business and will keep all software solutions running smoothly, without input.

10: Visualize your patch management

Make sure you can see a graphic representation of your patch management, tailored by severity and whether the patch requires a reboot or user interaction. This also fundamentally supports measurement and service level agreements by reporting SLAs in a way that’s visual. Not only will this help with compliance, but it will demonstrate that IT is making a difference to the business. This makes for better relationships throughout an organisation, whether internal or external.

The Evolution of Security Information and Event Management (SIEM)

Don't get stung by SQL Injection attacks

Takeaway: SQL Injection is no new arrival on the scene, yet high-profile attacks still occur. Alfonso Barreiro lists the basic measures to take to help mitigate the threat.

Despite being known for some time, SQL Injection attacks continue to be one of the most frequent ways a website can be compromised. It has been highly publicized recently as the main tool used in the attacks of high profile organizations such as Sony, PBS, and HBGary, but many misconceptions about it still remain.

What is SQL Injection?

SQL Injection basically inserts (”injects”) a SQL command to be run at a backend database by using input data that has not been properly validated in an application. For example, a login web page usually requires a username and a password. The web application uses a SQL command to validate the username/password combination and provides the user with information. The normal SQL command could take the following form:

SELECT * FROM Table WHERE UserName = ‘$User' AND Password = ‘$Pass';

In the previous example, $User is the username and $Pass is the password submitted on the web page by a user. The quotes surrounding both inputs are part of the query and set them up as literal text strings.

A regular user entering the username of “Michael” with the password “password” would result in the following command being executed:

SELECT * FROM Table WHERE UserName = ‘Michael' AND Password = ‘password';

The command would return all fields from the record in the table where the username and password match. An attacker however, could enter a single quote (´) in the username field and since the input is actually being parsed literally, the resulting command would be executed instead:

SELECT * FROM Table WHERE UserName = ´´´ AND Password = ‘';

This would then generate a syntax error. This is the proof the attacker would need to confirm that this particular login web page is vulnerable to injection attacks. The attacker could then insert the following in the username field:

hacker' OR 1=1; --

The resulting command would then become:

SELECT * FROM Table WHERE UserName = ‘hacker' OR 1=1; --' AND Password = ‘';

Here the pair of hyphens (–) represent the start of a comment, so from that point forward the text is ignored. The real command would be:

SELECT * FROM Table WHERE UserName = ‘hacker' OR 1=1;

The expression 1=1 is always evaluated as true for all records and since a logical OR expression is always evaluated as true when at least one of the components of the expression is true, this SQL command will always return data from the table (assuming it’s not empty).

This is a basic example, but an attacker could be far more creative and include different SQL commands to be executed such as insert, update or delete.

How to protect your applications

There are several ways to reduce your web applications’ exposure to SQL injection attacks, but as with many security measures, a layered approach in which all of the available mitigations are in place would be ideal.

Configure error handling

In the previous example, a syntax error revealed that the web form could be vulnerable to SQL Injection. Ensuring that error messages are consistent and do not contain debugging information (the default for many programming frameworks) could deny an attacker the information needed to refine an attack.

However, by only using generic error messages and not applying other defense mechanisms, it only makes a SQL injection attack more difficult, not impossible. This is known as Blind SQL Injection, which is identical to a normal SQL Injection attack, but it does not rely on error feedback from the server for refinement. This may slow down an attacker, but the end result is the same and just as dangerous.

Sanitize the input

Ensure that the user inputs do not contain dangerous characters or code. The recommended method is to create a “whitelist” of accepted inputs, depending on what should be the expected response. This not only helps in protecting against SQL Injection, but also avoids typos or other errors from being stored in your database. Note that this is not always practical since sometimes there are some fields where a “dangerous” character could be valid. For example, in a “last name” field, O’Brian includes a quote, but in the context of the entry, it’s a valid character.

Use parameterization

Though input sanitation helps, it still means that the user input could be considered part of a SQL command. Using prepared statements, parameterized queries or stored procedures (which are all supported in some way by essentially all databases), allows for a clear separation between data (the user input) and the command itself (the SQL programming). The input would be considered just “data” and some proper validation would be applied to it.

When using stored procedures remember that within it you can still create SQL commands dynamically, defeating its purpose in protecting against SQL Injection.

Apply the principle of least privilege and role separation

Whenever possible, create accounts that have the minimum amount of privileges needed for the task they need to perform. It shouldn’t be necessary to run a database application during day to day operations as a database administrator. This way a successful attack will not immediately grant access to the rest of the data or the server environment.

This is not a comprehensive guide on SQL Injection, as there are other potential avenues for attacks. The mitigation techniques described here are specific for countering SQL Injections, but as always, do not underestimate other basic layers of security to protect your data.