Monday, February 27, 2017

This blog not affected by the memory-leak of Cloudflare

In the post 'Implementing https on Blogger using Cloudflare' I describe how I utilize Cloudflare services to protect this blog. Unfortunately, we all noticed that Cloudflare has suffered from a tremendous memory-leak which was announced Friday, February the 24th.

This leak (a bit referred to as #cloudbleed) is extensively covered in the following posts.
On February the 24th I also got confirmation that this blog has not been affected by the memory leak in the html-parser of Cloudflare.

So, no worries in that regard concerning this blog.

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.

Monday, February 6, 2017

Tech-Sec Guideline: Safe defaults and Hardening

Guideline: Safe defaults and Hardening

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

Everything should have a secure default in such a way that access and functionalities are always explicitly granted, instead of implicitly. Functionality and features should always be disabled or uninstalled whenever it is not needed for the system or component to operate according to the needs of business or IT. Any of the already present security features should be enabled whenever possible.

Hardening are much like the same, although there are some differences. Hardening is about making the software, system or other components as hard as possible. Everything that is disabled or uninstalled is something that you don't have to worry about. It is a process in which, for instance, an Operating System is configured in such a way that weaknesses are limited wherever possible. In case of Microsoft Windows Server, think about configuring the register to disable weak ciphers and disabling the FTP-service.

It is also about enabling (or at least not disabling) security features that are incorporated with the software or system. Again, in case of Microsoft Windows Server, think about leaving the Local Firewall on and configure it, instead of disabling the service. The result should be a piece of software or system that utilize all security features while disabling all unused features to reduce the attack vector that accompanies the software or system.


Safe defaults has in essence the same principle as hardening, but there is a small difference. Where hardening is done after the creation of the software or system, safe defaults is all about pre-configuring. It is the same process as hardening, but everything is automated and deployed beforehand. Wherever possible, hardening should be a step in creating safe defaults for a piece of software or system. When a new Virtual Server is being deployed, all hardening steps should be as far as possible be automated, depending on the needs for the Virtual Server.

More information from Wikipedia about Environment Hardening.

Friday, February 3, 2017

Tech-Sec Guideline: Compartmentalization

Guideline: Compartmentalization

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

On every level of the technology stack there should be a reasonable amount of compartmentalization of components, systems and zones. Every crossover between two or more compartments are to be managed through ‘mediators’ that can manage and secure the access between them.

A striking analogy of this principle is that of a ship. Every (larger) ship is built in compartments. When a breach in the outer-wall has happened, the compartments makes sure that the flooding won't impact the entire ship. This principle can and should applied in technology also.

The principle of compartmentalization is to prevent that a breach does not impact the entire infrastructure, but only a small(er) part of it. In a, for instance, often less protected Test-environment a breach can occur more easily than a Production-environment. When these are properly compartmentalized, a crossover might be not possible and a full-scale data-leakage then can be prevented.

Compartmentalization can be applied on multiple levels within technology and you can do it as extreme as you want. Remember that there is a trade-off when it comes to compartmentalization of systems and environments. Because every transaction that needs to crossover to another compartment needs to be validated before it is allowed. It will require maintenance (which could be automated to some degree), and it will take for sure resources like processing power.

More information from Wikipedia about Compartmentalization.

Wednesday, February 1, 2017

Tech-Sec Guideline: Defense in Depth and Ubiquitous Security

Guideline: Defense in Depth and Ubiquitous Security

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

There should be a redundancy of security Controls within the environment and security Controls should be ubiquitous (everywhere present). When one layer fails or gets breached, another one should step in automatically.

The analogy of the castle has its place with this guideline also. A castle consist of multiple layers of defense. Think about the trenches, bridges, outer-walls, inner-walls and towers. The entire security is a multitude of such controls and where one fails, another controls steps in. In the end it is not about making it impenetrable, but to slow down the progress of the breach. And when it is slow enough, there is a good chance you can kill the attack-chain. This is called defense in depth.


Ubiquitous security has in essence the same meaning, but the underlying principle is somewhat different than that of defense in depth. Ubiquitous security means that it is security that is everywhere around you. It also beholds the guideline of Security by Design to make it possible. This type of security means that you don't have to think about using it, it is just there.

Much like the airbag, seat-belts, electronic brake system (EBS), lane detection and what not. And also traffic lights, traffic signs, road-repairs and traffic-police are examples of security controls to make safe driving possible. When users roam your network, do not only incorporate advanced security controls for a specific application, but also in every aspect of their work in a usable manner.

More information from OWASP about Defense in depth.