Thursday, February 16, 2017

Privacy Guidelines: Consent, Purpose, and Retention

Guidelines: Consent, Purpose, and Retention

Part of: Privacy Guidelines
OverviewBuilding a set of Guidelines for Security and Privacy

Below are the guidelines for privacy with the elements of consent, purpose and retention. Whenever organization is mentioned, you can read businesses, healthcare and government. Whenever people is mentioned, you can read customers, consumers, employees, patients and clients. Data in this case is in the category of Personal Identifiable Information (PII) which is subject to national and EU law and regulations.

Only collect with consent

Data is only collected with consent of the subject of the data.

Meaning that you don't collect explicit or implicit data on people without them knowing about it and without the consent of them to do so.

Only collect for purpose

Data is only collected for the business function that it is strictly needed for.

In essence, make sure that you don't over-collect data about people. Data that is not needed for the business to operate is data that should not be collected.

Destroy after use

Data is only kept for the time that it is strictly needed for the processing or as required by law.

Don't keep data about people longer than is needed for the purpose. Whenever the organization-people relation has ended, delete the data. Just keep the data that you are required to by law. Make sure the retention time is within those boundaries.

Only enrich within purpose

Data enrichment is only done within the context of the initial collection and consent of the data.

You can profile and track people to an incredible extent. Beside that you need consent for this profiling, the profiling itself my not excessively step outside the boundaries of the purpose of your organization.

Designate Data Ownership

Data always has an owner, or at the least a steward, who upholds the Security Guidelines and Standards.

Data, just as systems and services, need an owner. Data can travel through many systems and although all those systems might have owners, the actually can't own the data because it is shared. When data has an owner, it can have the proper attention it needs for things like consent, purpose and retention.

Wednesday, February 15, 2017

Info-Sec Guideline: Information Cryptography

Guideline: Information Cryptography

Part of: Information Security Guidelines
OverviewBuilding a set of Guidelines for Security and Privacy

Data transport channels over which any type of information is being transmitted using a publicly available communications channel must always be encrypted using modern and open standards. In addition, data transported by physical means is always done using an encrypted carrier.

Wikipedia: The Enigma machine
Encryption is one of the key security controls that can help keep you data safe from prying eyes. It is as old as the ancient Romans and Greeks and played a major role in World War II with the Enigma machine. But encryption has a (sometimes significant) trade-off. And that is that of resources. It costs time and energy to do its work. The compute time varies across different algorithms, key-lengths and implementations. Despite these trade-offs, the mindset should be that of: “Encrypt Everything!”.

Whenever data is transported using physical carriers, at least the carrier itself should be encrypted. Think about USB-sticks utilizing hardware based encryption. In addition, think about encrypting the data itself also. When data is transported using communications channels, the channel over which the data flows should be encrypted. This can be done in multiple ways, depending on the needs and available options.

In short, make sure that no one can eavesdrop your data and encrypt the means that is used for the transport.

More information from Teusink.eu about Encryption and Hashing.
More information from Wikipedia about Cryptography and Encryption.

Tuesday, February 14, 2017

Info-Sec Guideline: Complete Authorization

Guideline: Complete Authorization

Part of: Information Security Guidelines
OverviewBuilding a set of Guidelines for Security and Privacy

Every form of access is based on a complete authorization scheme (identification -> authentication -> authorization) and authorization is never implicitly granted.

When access to a system is needed, authorizations are required. Such authorization can be granted implicitly and explicitly. Implicit authorizations are dangerous, because a system assumes that because you are on the network or domain, you can access everything else within that context. Explicit authorization prevents that from happening. Even when you have access to a system or domain, specific authorizations are still validated before allowing (further) access.

In an information system in a hospital an assistant might access contact details about a patient. But it would violate the patient’s medical confidentiality when the assistant can also access the medical records stored in the database. Therefore, the person’s identity must be authenticated and based on that authorizations needs to be granted or not. Based on this information the doctor would see more information than the assistant.

Explicit authorization can be done with security tickets or tokens traveling with the identity. But the mere fact that the token exists should not lead to access. The ticket or token should be validated for proper authorization before access is granted.

More information from Wikipedia about Authorization.

Monday, February 13, 2017

Info-Sec Guideline: Segregation of Duties

Guideline: Segregation of Duties

Part of: Information Security Guidelines
OverviewBuilding a set of Guidelines for Security and Privacy

Wherever possible there must be as much segregation of duties between the positions of employees that have a conflict of interests with each other. Such duties should be divided over different employees.
Image of sqlity.net
This guideline is about preventing mistakes and unauthorized transactions which leads to integrity issues or fraud. A developer who submits code to the repository is not the developer who should be able to accept it. A second developer should accept (or decline) the submission to establish the four-eye principle. Another example is that of a bank-employee requesting a loan for a customer. Another employee should accept (or decline) the request.

The main goal is to make sure that not one single person is able to initiate and end a (business) process. Especially in the cases where there are financial transactions involved or where the integrity of data or systems is important to maintain.

More information from Wikipedia about Separation of duties.

Friday, February 10, 2017

Info-Sec Guideline: Least Privilege

Guideline: Least Privilege

Part of: Information Security Guidelines
OverviewBuilding a set of Guidelines for Security and Privacy

Employees and (automated) processes should only have access rights explicitly needed to carry out the functions and duties that needs to be carried out in the context of the work that needs to be done.

This guideline seems an open door, but it many cases it is not. Least privilege is a very important aim, but due to many (business) processes there is often a so called “authorization”-creep. Over the course of the life-cycle of an account (if there is even any) authorizations are constantly added.
Meme Generator
Most notable is that of the user accounts. An employee gets hired, perhaps as a trainee. It then likely has the least privilege principle properly applied. But when such an employee gets other positions in the company the account gets additional authorizations. The authorizations that should be revoked are often not revoked though. Resulting in an account that can be used for many more purposes than it should according to the position the user has in the company.

When every user, administrator or service accounts are created, apply a life-cycle management through the account’s entire life-cycle. When the purpose of an account changes, also change its corresponding authorizations.

You can even take it a step further to make privileges context aware. With limiting privileges based on context (when you might need access to data and when not) is a way to orchestrate the 'need to know' principle.

More information from Wikipedia about Principle of least privilege.

Tuesday, February 7, 2017

Tech-Sec Guideline: Patch and Life Cycle Management

Guideline: Patch and Life Cycle Management

Part of: Technology Security Guidelines
OverviewBuilding a set of Guidelines for Security and Privacy

Every piece of software and firmware of all systems and components should be maintained by its supplier and the latest security patches should always be installed. No software, firmware or hardware is to be end-of-life or dropped of support by its supplier.


In most notable, if not all, hacks lack of patch management was a key-ingredient of a successful breach. Known vulnerabilities are often not patched which leaves the gates to the environment open to attack. Not patching vulnerabilities is like not stopping a wound to bleed. And always install security patches as fast as possible, to make the window for an attack as small as possible.

And it is not only about patch management. Most too often software is being used that has exceed its life cycle, resulting in the use of software that receives no more support. No more support, means no more security fixes. Although you have installed 'all' security patches, you are likely to be vulnerable. Often security vulnerabilities, or its exploits, are reverse engineered to older not support releases. Which then result in a vulnerable system that will never receive a fix.

Never skip a security patch, and never use non-supported software. Ever.

More information from Wikipedia about Patch (computing) and Lifecycle management.