I have encountered several, ‘secure, encrypted drives’ for sale which are nothing more than a drive sealed within a pin-protected casing. Thus, any security minded users who purchase such a device will be storing their sensitive data assets with the impression they are protected and secured by encryption – when in fact they are open to anyone who may remove the drive from its casing to view the insecure content.

Mitigation: If you care about robust security of your files, only user Certified,
trusted, encrypted drives which are built to the FIPS-140/2 Standard.

A Nottingham based Financial Services business were unfortunate enough to be hit with a zero-day computer virus, which spread with some speed within their operational environment. A Major Incident Board was convened, and a team was brought together including senior members of the IT security team, and directors from the companies Technical Services Board. They concluded that to deploy the style of patch required in the most expedient way would be achieved by changing the domain policy to open up access to each of the client systems (desktops/laptops), which would be followed up by a quick push of the updated .DAT signatures, quickly followed by a reapplication of the required domain policy to bring all systems back to their original security posture. Once this was completed, the team stood down; however, it was soon apparent that something had gone wrong when members of the IT Security Team were receiving calls from ordinary users reporting that, in one case they could see all files located on the Human Resources Director’s local drive, and the calls continued. The issue was, what had not been appreciated by the technical Services Board Director, and the associated Information Security Team was, whilst you may remove the permissions across the domain with the click of a box, to reapply them requires end-system action of a reboot to reinstate the required level of security posture – thus all systems and stored were exposed cross-domain!

Mitigation:

1. Ensure that those in key positions are fully trained and above all competent.
2. Where there is need to take additional steps to secure data (e.g., the HR  Director) encrypt the locally stored files.
3. Consider utilising off system, secure, encrypted removable drives to secure sensitive data.

I recall when working for a Local Authority in the East Midlands with an IT Director who could never surprise his staff. He commented to me, ‘no matter what I tell the team at our town hall meetings, they always seem to know before I pass on the information’. That was because they did, as due to poor security and open folders, some members of the IT Team had full access to the stored data and communications of said IT Director – so yes, they were always aware what was going on!

Mitigation:

1. Ensure that folders and storage areas are appropriately protected, and not visible to any members of the IT Team (or any other unauthorised user or that matter).
2. With any sensitive data it is always best practice to store such sensitive data-objects offline, on removable, encrypted storage devices.

Don’t just take our word for it, test our products before committing by requesting a free 30-day evaluation

Try Now

I have previously worked as a Consultant for a London based UK Government Agency who worked on sensitive data of the highest classifications. Given their concern over data security, they ran a project to virtualise all desktops/laptops, which were limited to only storing data on servers located within the secured computer room. However, they overlooked the fact that on every floor in the building stood an MFD (Multi Functional Device) AKA, a computer, IP addressable, with on-board Print Server, Spooler, Web Server, Hard Drive(s) Storage, that just happens to offer printing facilities, on which the drives were accessible, and of course on this occasion not encrypted, leaving the sensitive data open to both physical and logical abuse!

 

Mitigation:

1. Always run a risk assessment of data flows and storage when engaging such a project.
2. Ensure that where there are configuration options (and there were) apply a level of encryption to the dives to secure any stored data objects.
3. Where physical access may be achieved to the on-board drives, always ensure they are physically secure by lock-and-key.
4. When these devices reach end-of-operational life, at the very least ensure the disks are securely overwritten/purged – at best, physically destroyed.

Whilst there may be a great faith in the local security associated with say, Windows, or other such operating systems, this can be a false sense of security when we consider the security of the data objects stored thereon. Take the average Windows desktop or laptop – our user has the full confidence that only they can get to the on-board data objects as they are using a very strong password, along with the associated logon credentials – so all is secure and tucked away from the illicit view of others. However, what our user needs to realise is that, notwithstanding their security credentials, to gain access to the stored data, it is a simple case of physically removing the drive, and then mounting it on to an awaiting laptop via an interface, such as the USB3.0 TO ODE/SATA device – from there on, full access to said content may be enjoyed.

 

Mitigation:

1. Encrypt Local Drives with Bitlocker etc (Keep Keys on USB, or ensure the machine is accommodated with a TPM Chip (Trusted Platform Module).
2. Better still, use a removable, FIPS-140/2 encrypted drive accommodated with some form of additional security mechanisms – say Pin Protected.

If you are using Cloud, and most are in some form or another – ensure that you have completed a full Due Diligence of the Third-Party Supplier, remembering that Cloud, and Third-Party Supply Chains are a known known potential area to introduce insecurity. Consider technologies such as AWS S3 Buckets, and ensure they are secured. Cloud environments are one of those areas which can reveal a lot to an OSINT (Open-Source Intelligence) mission which can lead to the acquisition of valuable information. To mitigate any potential exposure when using a Third Party (TP) Services, or Cloud, some may consider encrypting the sensitive objects within the TP environment, or on the Cloud to secure them from prying eyes, should the external service fall victim to a hack or compromise – an excellent security consideration. However, the user organisation must keep in mind that, dependent on how the actual encryption keys are stored (protected) within the TP, or on the Cloud, it may still be the case that if the TP/Cloud is subject to a hack/compromise, it should be anticipated that the attackers will go looking for the encryption keys or Digital Certificates which have been employed to actually secure the, supposed, secured assets! In my experience, this is not a matter of theoretical consideration, but a circumstance which I, and many others have observed in real-world attacks, in which the actual security credentials to the golden nuggets of data have also been stored in an exposed, inappropriate, insecure way, and thus also fallen to compromise.

Mitigation:

1. Consider running your own RED-TEAM activity against any procured, or to be procured service to gain an insight into the overall footprint.
2. Conduct an in-depth review of the service provider at all levels.
3. Once procured and operational, ensure regular service update meetings are held – say every three months.
4. Where valuable logical assets are implicated, consider utilising an Escrow agreement to accommodate security over such assets lodged with the Third Party (Just in case). Where there is an objective to achieve a secure, robust security schema to leverage encryption within a TP, or on the Cloud, one complimentary methodology is to store Digital Certificates, and Encryption Keys external to the TP/Cloud environment, under the sole custodianship of the user, or user organisation. This approach offers the most pragmatic, and secure methodology to maximise the security footprint of the deployment. Thus, never exposing the security credentials to any potential of a sniffing attack, and always ensuring that such security credentials are held under the safe, and sole custodianship of the owner of the sensitive data -objects.

Frequently I have witnessed the disposal of devices such as MFD’s, mobile phones, IoT devices, printers, computers, and servers. On each of these occasions, these data-holding systems have been disposed of, containing corporate and sensitive data. From mobile phones which have been allowed to connect to corporate systems, to hard drives populated with Local Authority data relating to case files of vulnerable children.

Mitigation:

1. Create and promulgate a Policy/Process to drive the way end-of-life equipment is processed out from the business.
2. Create a register to document the end-of-life journey that all devices take.
3. Hold all such devices in physically secure location until such time they are correctly processed in accord with the mandated policy/process.

Don’t suffer from tunnel vision when securing you data assets – remember, it not just about the digital aspects, but also needs to encompass the other potential carriers of insecurity – e.g., paper. I recall my very first contract on the South Coast. The Project Manager said to me on my very first day, ‘you need to make a difference and quick to convince the executive we need to look at the company’s overall security posture’. 4 hours later I presented him with a sack, full of paper holding client personal details, credit card information, and client bank account details, all of which had been cast out into the general waste bins.

Mitigations:

1. Accommodate the facilities with secure, locked, clearly marked classified waste bins.
2. Produce and promulgate a policy to dive the mandated requirements.
3. Consider using on on-site Secure Paper Shredding/Disposal Service.
4. Educate end users.

MetaData is data about data, and can provide much, unintentional information which can range from user profiling, departmental data, telephone extensions, right down to IP Addresses and software versions.  Consider the fact that such unintended information can be leveraged to adverse interest to footprint and target an organization, or individual, and can provide a very good launch-point for a social engineering attack.

Mitigation:

1. Employ some form of methodology to remove any unwanted MetaData from documents prior to release.
2. It may be obvious but ensure that documents are not released with the underlying Track Changes embedded.
3. Consider using secured PDF formats (locked down, encrypted with password or certificate).

The area of Domain Name System is so often overlooked, and yet is as important to any penetration test focused on aspects of IP Addressing. As with some of the aforementioned areas, when inspected under the gaze of an OSINT Methodology, DNS can also produce much intelligence which may be leveraged to attack the organisation. From Zone Transfer, which in one case led to identifying servers with Hard Coded Users ID and password within scripts, through to the discovery of poor security DNS postures, and other such associated aspects, such as lack of SPF (Sender Policy Framework). DNS Security is a very big area, and one I would encourage you to peruse in the interest of a robust security posture – if that is, you have not already done so.

See RFC 4033 URL for more information:
https://datatracker.ietf.org/doc/html/rfc4033

Mitigation:

1. Review your organisations DNS environments – include DNS in your penetration testing programmes.
2. Conduct regular security inspections to ensure your DNS environments are secure and serving the required security posture.
3. If not familiar, read RFC 4033.