Author: Robert Broxup

Practical Steps to Improve Software Management

Robert Broxup

Software Asset Management (SAM) is more than just a software licensing exercise – it is about maintaining control, reducing risk, and maximising value from your software investments. Effective SAM practices help organisations avoid compliance issues, reduce unnecessary costs, and improve operational efficiency. The following key points provide a practical foundation for managing software assets with confidence.

  • Maintain an accurate inventory of authorised software. Knowing what is allowed makes identifying and removing unauthorised software installations more manageable.
  • Ensure that all your software is correctly licensed. Avoid unnecessary purchasing of software licences by limiting usage based on job roles. Reconcile software purchases with software usage.
  • Maintain control over who can install software packages. Avoid ad hoc software installations and proliferation to reduce licence exposure and cyber threats.
  • Ensure that authorised software is up to date and supported by vendors. Reduce exploitable software vulnerabilities.
  • Segregate business-critical software from other lower priority systems. Avoid less important systems from impacting the business.
  • Keep control of software support costs. Accurate information about software usage contributes to avoiding excessively priced support contracts.
  • Choose the right product to fit your business environment. Ensure the solution works with existing platforms and operating systems, and the software works out of the box or with minimum configuration. Avoid the trap of buying software and then paying expensive project and development costs to make it fit for purpose.

Good SAM practices create a more stable, secure, and cost-effective IT environment. By actively managing software across its lifecycle, from procurement to retirement, organisations can minimise risk, reduce waste, and better align IT with business objectives. A little discipline in this area can go a long way toward supporting compliance, security, and more effective IT spend.

Application Whitelisting

Robert Broxup

Application whitelisting is a proactive security control built on a simple principle: only explicitly trusted applications are allowed to run. Instead of trying to detect and block everything malicious, application whitelisting focuses on permitting only approved software to run. Everything else is denied by default. This deny-by-default approach significantly reduces the risk of malware, shadow IT, and unauthorised activity.

When implemented correctly, whitelisting strengthens protection, enhances control, and simplifies endpoint monitoring. However, like any high-assurance control, it demands structure, ongoing oversight, and organisational commitment.

Benefits of Application Whitelisting:

  • Reduces the risk of malware infection by blocking unapproved executables before they can run.
  • Blocks unauthorised software installations that could introduce vulnerabilities or licensing exposure.
  • Limits shadow IT, ensuring that only vetted tools are used within the business.
  • Streamlines monitoring by enabling teams to focus on deviations from a known-good baseline.
  • Supports compliance by enforcing clear software control policies.

At its core, whitelisting software distinguishes between approved and unapproved applications using a range of attributes:

  • File name, location, and file size
  • Digital signature from the software publisher
  • Cryptographic hash of the file

Among these, the cryptographic hash provides the highest assurance of integrity. It ensures that only an exact version of an approved file can execute. Any modification, even minor, would result in a different hash and be blocked. This makes it far harder for an attacker to substitute or tamper with software undetected.

Relying solely on weaker attributes such as file name or file path introduces opportunities for circumvention. A malicious file could simply be renamed or placed in a whitelisted directory. Strong whitelisting solutions use multiple attributes in combination, with hashes providing definitive assurance of integrity.

Key considerations when building an effective application whitelist:

  • Establish a clean baseline – use a standard build as a reference point. Perform a full scan to define an initial whitelist that can govern other endpoints.
  • Identify other software – business environments evolve and software in use is not always known, and legacy software could be part of critical business processes. Using only a standard build to create a whitelist would likely cause failures and inconvenience staff and business activities.

Challenges and considerations:

  • Operational disruption – if the whitelist is incomplete or poorly maintained, legitimate users or systems may be blocked from essential tools.
  • Ongoing maintenance – software updates, new business requirements, and evolving job roles all require updates to the whitelist.
  • Resource demand – maintaining accuracy requires time, policy oversight, and either dedicated staff or vendor support.

Phased deployment minimises disruption. Begin with a pilot group to identify issues before implementing a wider rollout. A robust whitelisting policy should define approval criteria, update procedures, and exception handling. Regular audits of the whitelist are essential to avoid drift and reduce unnecessary entries.

Application whitelisting is a powerful control that shifts focus from blocking threats to enforcing trusted execution. If implemented correctly, it can reduce attack surface, mitigate malware threats, and bring clarity to what software runs across your environment. A whitelist must be carefully constructed, actively maintained, and consistently enforced. Not treated as a one-time project but as an ongoing control.

The GDPR Challenge

Robert Broxup

Issues surrounding the General Data Protection Regulations (GDPR) have been hot topics for some time, and many have said that 2018 will be all about GDPR and very little of anything else. A key question here is to what extent does the implementation of GDPR have the potential to reduce the overall level of security for individuals and their data.

With the right to access and to rectify personal data, a growing number of companies will choose to solve this problem by providing online access to their data. This approach takes responsibility for the accuracy of data away from companies and places it firmly in the hands of individuals.

  • Companies will need to organise their data to correlate all data for a single individual across multiple systems to provide a single view of data. Having data collated in such a way has the potential to make it easier for someone to gain unlawful access to customer data. Although the data may be physically distributed across the globe, to access all data, it still needs to be virtually in one place.
  • Providing online access to customer data will require login credentials. Multiplying this by the number of companies making customer data available online could quite drastically increase the number of passwords people need to manage. The risk and attack surface area increases with every registered online account.
  • If businesses offer the right to erase all personal data online, individuals could easily find themselves registering to carry out the erasure. However, it is acceptable under GDPR to email a business asking them to delete all data, and for them to delete the data without forcing people to jump through hoops.
  • Companies that don’t currently provide an online account for their services, such as for making a simple online purchase, will be able to use GDPR as a justification for everyone to register at the time of purchase and require an account. Again, the number of login credentials needed will increase further.
  • Providing the online means to export all data to comply with data portability will make life much easier for hackers wishing to steal data if accounts are compromised. Access will be to the same data provided online, except instead of needing to stay logged in and possibly make screenshots or screen scrape data, they can use a download option.
  • In the recruitment sector, it is common for individuals to have their data with 100s if not 1000s of individual recruitment businesses. As individual recruiters move from company to company, the data often goes with them, so the number of recruitment firms holding personal information is in practice much higher. Many job seekers could find themselves needing to manage many online accounts to the point of it being unmanageable.

The more online accounts people need to have, the less secure the situation becomes. There is a saturation point where people will shut off and become more complacent with security. If people do attempt to have different login credentials for various systems, there is likely to be a point where such good intentions break down. They become bored with managing their accounts online and their security becomes compromised. It is similar to the argument that if a password is too complicated to remember, and a password vault not used, users will write down their passwords.

Everyone reading this blog will probably know at least one person who has a notebook in a drawer for all their passwords, and you may know precisely where it is just in case something happens. The number of online account requirements is increasing. GDPR is causing this number to grow faster, and the whole idea of online accounts and passwords will keep more people awake at night.

When Passing the Audit Doesn’t Solve the Problem

Robert Broxup

While responding to requirements identified during an IT audit, both internal and external, I have observed many cases where the identified need was to demonstrate that an implementation plan was in place to mitigate several risks. Instinctively one would think that undertaking the implementation was implied in the requirement, but this is often far from the truth.

Upon presenting the plan in detail along with expected results at each stage of the implementation, the management reminded us that the action was specifically to demonstrate that a detailed plan existed.

The auditor’s report did not explicitly state that we must implement the plan. Consequently, management chose not to sanction further work.

From the auditor’s point of view, defining an action in the form of ‘tell me how you are going to fix this problem’ is logical as a next step. However, far too often, it results in a focus on closing audit actions rather than resolving the underlying issue that caused the audit action to be defined. As security professionals, we have a duty to decision-makers to challenge the requirements under these conditions, by illustrating the potential consequences of inaction.