The Security Evangelist, Lesson III: Integrity

This post was originally posted on the Workshare blog at https://www.workshare.com/blog/the-security-evangelist-lesson-iii-integrit.

In this post, I am going to talk about integrity.
When talking about security, integrity is one of those factors that most people take for granted. At its most basic level, integrity is about making sure that the data you put somewhere is exactly what you get out, that it has not been corrupted or modified in any sense.
For individuals, this means that the data must be kept exactly as you put it in. You do not want the data to become corrupted, accidentally deleted or lost. Nobody wants to lose those really cute pictures of their baby or their honeymoon, or to realize that the 10 hours they spent updating a CV have been wasted because the document is corrupt.
In a business setting, there are multiple types of data, they may have different levels of importance, but it is critical that the integrity is maintained on all of them. It is important that the file data doesn’t get modified inadvertently or by unauthorized users, but also that any modifications to the file’s content are known and understood.
There is also a need to prove that integrity has been maintained at all times, with strict requirements for compliance or auditing purposes.
Integrity can be compromised in multiple ways, which may be malicious or not. Some of the typical ones are:
- Internal 

• People accidentally modify or delete data
• Misconfiguration allows modification of data by unauthorized personnel
• Lack of logging and monitoring prevents the company from proving that the data has not been modified
• Lack of logging prevent the identification of change authors
• Sharing of credentials prevent determining who is responsible for modification
• Software bugs cause data corruption

- External

• Attackers modify customer or critical data
• Misconfiguration enables attackers to modify confidential information
• Human error causes confidential data to be corrupted

The three main ways of ensuring data integrity are:

1. Restricting access to the data
2. Identification of all the changes and who made them
3. Being able to verify all changes applied to a set of data against a known baseline

As usual with security, it is not enough to set and enforce a static set of rules, you should continuously review them, monitor for unauthorized access and verify that the audit log contains enough accurate information.
A safe assumption to make is that you lose control of data once it leaves your system. If you want to ensure that you can verify the data you receive from external actors, you have to check anything they send you against the original document that you sent out. Workshare Comparison Edition enables you to get a clear overview of everything that has been changed between two versions of a document, no matter how it is sent or received. And, with the Sharing Edition you get full access to compare any two versions of an existing document history and a full audit log on who accesses a document or uploads new versions.
In the next post, we will talk about how you can prove whether data integrity has been compromised.

The P-word

When working in Agile environments, you will often find a complete aversion to the infamous P-word.

I bet you're asking what's that word? In case you haven't guessed it, it's process.

Yes, the typical big-enterprise approach of change advisory board meetings being the cut-off for new features being released, with red tape all over, signed forms in triplicate and enough bureaucracy to make Asterix go mad is pretty much anathema to agile but, as everything, there is a middle-ground where things are just right.

Every single thing you do in a regular basis has its own process. It may not be the most efficient, it may be improvable but it does work. After all, you use it regularly and it does produce results.

Every workday I wake up, usually get up on my second alarm (yes, I have it set up with two alarms), do my exercises, have a shower, get dressed, have breakfast, brush my teeth, leave the house. It takes me about 45 minutes to go through all that. I can probably speed it up (increase efficiency) to 25 to 30 minutes but I don't need to, so I don't normally do so, unless I am running late.

As a developer, your normal code writing process will be something like:

1. Write a user story.
2. Split the story into smaller sections you can work on individually.
3. Start section.
4. Write code.
5. Write tests.
6. Run tests.
7. If the tests don't pass, go to 4 or 5 to fix the issue.
8. Do a test of the feature at its current state (I am assuming that regression and integration tests run automatically).
9. If the test fails, troubleshoot and then go to 4 or 5 to fix the issue.
10. Commit to local source repository.
11. If there are any sections left, go to 3
12. Push to the main source repository.

There may be a lot more steps but, more or less you're doing something like this. This is all in your head and it's great but, how do you share this? Well, the answer is process (and documentation).

Processes are not designed to hinder engineers or to make things difficult for everyone, they are designed to make sure that people share a way to do things and the knowledge of what has been done and how it has been done.

Let's look at the typical way of working with Github, the pull request. Someone wants a feature added or a bug fixed, so they:
- Clone the repository
- Create a new branch
- Do all their work in the branch
- When the branch is ready, they create a pull request
- The project owner / maintainer, will then review the request and either send it back for fixing (with suggestions) or merge it into mainline

This is simple but this process does not need anything else.

Now, let's say that you are using this process in your company (well done, you're already doing code reviews!) and are required to add Change Management.  How do we do it? Well, you can do it in a reasonably simple way by adding a couple of requirements:

1. Master is your Production branch.
2. Every commit requires a ticket number, referring to a user story or bug report with a fixed format (EG. ticket#1234 or [1234]) in the message.
3. Only people in the approvers group can merge into Master.

That's it! To have basic Change Management you only require 2 things: a way to understand what changes were made and why (the commit messages + ticket number) and a process for approving changes (the merging into Master).

So now, if we want to see when feature 1234 was added to the system we only need to know when it was merged into Master. Do you want to have a high-level view of the changes between two releases for the release notes? Get a list of the ticket numbers from version control and you are 90% there. Do you want to know who approved the changes? Look at who merged the code.

The key to not just agile processes, but process in general is to adapt the process to the existing way of doing things. Your company (or group) is already releasing something, you already have a process and it works. Instead of changing it completely, adapt it slightly and make it easy to adopt. You can always go back and refine it later.

If you can also provide value to the people affected by the process, you have a great chance at the process being accepted with low friction. Say, you provide them with automation that will save them time as part of the process implementation.

When possible, make it so it is impossible to do the wrong thing. If you require the ticket number of every commit, create a pre-commit hook that checks that the ticket exist and is open and enforce it as part of the standard environment. Soon, developers will be doing this automatically as part of the workflow and won't even notice anymore, but management will have all of the shiny reports they need and compliance will be ecstatic that you have a Change Management process.

The next time someone tells you that they want to set up process, instead of shutting them down and making them do the work from the outside, welcome them into your world and help them build the process around the way you already do things. You will be surprised how efficient this can be for everybody involved.

One final thing to mention is that automation and tooling can really help with process - nothing better than having someone doings things for you and to make sure that you don't forget anything.

Let me know your thoughts.

PS. If you did not get the Asterix reference, please watch The Twelve Tasks of Asterix and pay attention to Task #8.

The End of PPTP

MacOS Sierra, the latest version of the Apple OS has been out for a little while.

One of the most disruptive changes in this release is the removal of support for the PPTP protocol, used for establishing VPN connections which, for a long time, was the default way of doing VPNs in Microsoft systems.

While I have heard some people complaining about it, as a security professional, my opinion is that it was about time they did so. The PPTP protocol is not secure - it is not that the implementation is not secure, the actual protocol has flaws in its design that make it insecure. The only way to make it secure is to stop using it, so Apple supporting stop for it will force laggard IT departments to solve this issue once and for all.

For more information about the protocol, please see the following links:

• Point-to-Point Tunneling Protocol on Wikipedia.
• A Death Blow for PPTP, analysis of the issues with the protocol on H-Online.
• A Security Stack question with good links about the issues with PPTP.

On Recruiters (the good kind)

As a candidate and hiring manager, I have not got much love for recruiters. Most of the times, they are a necessary evil, but this post is not about those recruiters, just browse LinkedIn and you will find many examples of that.

This post is about good recruiters and how to build a relationship with them.

First of all, I have to say that finding a good recruiter is hard. Finding any person who excels at their job is hard anyway, the low bar to becoming a recruiter makes it even harder.

I am lucky enough to have a few people I have been working with for a while. They have all proven me that they are completely trustworthy and I will try to work with them as often as possible. A couple of them go as far as sending me offers for jobs in companies that are not their customers! Of course, that means that, if I get in, they will have someone who likes working for them, but still, it's a nice thing to do.

Common traits of a good recruiter:

• Communication: A good recruiter will be clear about what they are looking for and make sure that you get all the information you need. If you ask for more information, they will provide it as soon as possible or will chase it for you. If they need more information, they will ask for it.
• Focus: When they contact you, it will be because they really have something you may want. If they do not have it, they will not waste your time. They will not try to sell you just any job, only what you are looking for. They will not just spam you with endless keyword-matching emails.
• Continuous contact: They will keep in touch with you at a regular basis, even if it is just to tell you that they have nothing new.
• Efficiency: If they have something to talk to you, they always tell you directly - no point in beating around the bush.
• Responsiveness: They provide feedback or contact me as soon as possible. They return the calls, even if it is via email to let me know that they can't call me back.
• Honesty: They will not lie to you or give you the runaround and, when possible, they will tell you things straight away.
• Flexibility: Things change. Often. Adapting is not optional.
• Long-term vision: An immediate sale will not come above a long term relationship.

How do you get to build a good relationship with recruiters? It's simple, the above rules apply for you as well. Recruiters love a customer that goes the extra mile to make sure they have enough information on what's going on because, as you, they are extremely busy!

It goes without saying, a good recruiter will make your life a lot easier, make sure you look after them.

Microsoft's New Windows Patching Policy

As of last Tuesday Microsoft will no longer provide separate patches for Windows 7, 8.1, Servere 2008 R2, Server 2012 and Server 2012 R2 to address individual issues, the patches will all be bundled together in a 'monthly mega-patch'.

This might not sound like such a bad thing but this means is that it will no longer be possible to skip or revert functionality-breaking patches without also reverting security ones. So, should you hit an issue caused by the latest patch, your choice will be to have a functional or secure system, but not both.

Each patch now bundles together bugfixes, new features, some of which may be unwanted (like the telemetry ones) and security ones, increasing the footprint and so the possibility of the patch causing breakage.

It will also push Desktop users toward Windows 10, a system that, unless you use the most expensive versions of, offers you no control of which or when patches get applied.

While it's not the case yet, the apparent goal is to provide cumulative patches, which include the previous ones. This will exarcebate the problem of missing security patches, should you have to roll-back or skip a patch due to bugs.

So, once again, Microsoft ignores their customers and does what it is best for them, reducing the number of supported configurations.

Oh well! The silver lining to all this is that, working in a company that writes Windows desktop applications, we will now have to deal with far fewer patch levels when trying to troubleshoot customer issues.

For the full details go to:

Current changes: https://www.helpnetsecurity.com/2016/09/14/microsoft-ends-tuesday-patches/
Later changes: https://blogs.technet.microsoft.com/windowsitpro/2016/08/15/further-simplifying-servicing-model-for-windows-7-and-windows-8-1/

The Security Evangelist, Lesson II: Confidentiality

This post was originally posted in the Workshare blog as The Security Evangelist, Lesson II: Confidentiality.

Today I’m going to be talking about confidentiality and how to protect it.

Confidentiality is all about restricting access to information; ensuring that only those who are entitled to see certain data can get access to it. In plain English, it’s about keeping secrets.

As an individual, you make sure your personal data remains confidential by keeping it secret and not sharing information with those you do not know and trust. This protects your data.

The easiest example related to this is your credit card; I am completely sure that you do not give it away to anybody, that you keep it safely in your wallet or purse, and you would never give your PIN to anybody.

In a business, you have multiple types of confidential data: personal data, like your employee records; confidential data, like your business plans; and customer data, including account information. While all of them are important, there are different levels of confidentiality depending on how critical the data is.

The importance of the data can be determined by the impact that a confidentiality breach would have on the business overall. Damage can come in the shape of reputational damage, direct loss of business, legal liability and, in some cases, financial damage in the shape of fines or trading restrictions.

Unauthorized access can come in many ways. Some of the most typical ones are:

- Internal:

• People move jobs and they are not removed from relevant groups
• Misconfiguration allows access to restricted resources
• Sharing of credentials allows access to restricted data

- External:

• Attackers use vulnerabilities to attack the system and gain access
• Misconfiguration exposes confidential data
• Human error causes confidential data to be exposed

There are two main ways to ensure data remains confidential: 1) restricting access to the data and 2) auditing all access. It is not enough to set and enforce rules preventing people from accessing data, you also have to continuously review those rules and monitor for unauthorized access.

A safe assumption to make is that you lose control of data once it leaves your system. Your only option is to remove any confidential data before it leaves your system in order to protect it. With email, for example, Workshare provides Workshare Protect, which scans outgoing documents to remove any hidden metadata that may leak confidential information inadvertently or maliciously.

How do you ensure the confidentiality of your data?

Before anything else, you have to understand what data you control; what type of data it is and how you process it. This means going through every system your company manages, whether directly or through third parties, and understanding what it does and the level of access required for the normal functioning of the business.

Then you have to establish policies and controls around the handling of the data. This will ensure people understand how to manage data, critical or not, and what to do when something goes wrong. It also provides monitoring and metrics that enable you to assess events as they happen.

Finally, you must set up policies and processes to deal with data breaches. This is often an afterthought, but it is critical. In the event of a major breach, you do not want to be working out what to do, everything should be established in advance, including communications, reporting and crisis management. The criticality of this last step cannot be understated.

A good response can make the difference between containing a data breach and a company “going under” due to legal and financial penalties. For companies operating in the European Union, the new General Data Protection Regulation, coming into force in 2018, states that all breaches involving personal data must be reported immediately and that failure to do so may incur a fine of up to 4% of global revenue. In order to report, you need to know what is happening, and getting the processes and tools in place to manage this will take time and resources.

Once policies and controls are in place, it then becomes a matter of regularly reviewing them and taking any learnings from events and the way they are handled, no matter whether you are always successful or not.

It is often said that security is not a project, it is a process that needs continuous refinement. A system that is completely secure today may not be the same in the future as new technologies and vulnerabilities are discovered.

Yahoo: Dear, oh Dear!

Today Yahoo! finally confirmed what everybody expected, that they had a major security breach.

Many companies have had security breaches but I cannot think of many that have handled it as poorly as Yahoo!

The breach supposedly happened in 2014, 2 years ago, and it only comes out now. As a consumer, I can't wait for the EU General Data Protection Regulation to be in place - Yahoo would have been fined a nice 4% of its global revenue due to failing to promptly report the issue. And in this case, it's very, very likely that they would have gone for them, considering that it affects an estimated 500 million users.

There only was one announcement. On their Tumblr page. No announcement on the main Yahoo! site or Yahoo! Mail :

(if you squint and look carefully, notice that there is a mention of the hack on the trending news and, if you wait or are lucky, you will see it as one of the highlighted news). 
There are no emails sent to the users, at least, not to my old Yahoo account, which I do not use anymore but still gets emails and gets checked every so often, so it's still active. When you log in, you get the following welcome:

No mention of the breach. No mention of why you really, really, should change your password and security questions. No mention that you should change your password and security questions in any other system where you use the same information, just in case.

The announcement explains that 'The account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (the vast majority with bcrypt) and, in some cases, encrypted or unencrypted security questions and answers' - considering that the data seems to be available, a quick check against their systems should be able to confirm that this is the case, the 'may' here sounds like covering their backs.

Verizon, who are currently in the process of buying Yahoo!, mention that they only found out about the breach a couple of days ago and had 'limited information'. That should ring alarm bells everywhere and also makes me think that the only reason why the breach is coming out now is because Verizon are doing their due diligence and Yahoo!'s hand has been forced on this, otherwise it would have stayed hidden forever.

Finally, Yahoo mentions that the attack was 'state-sponsored'. If that's the case, why was the data available to buy in the market? Usually, states do not want to sell the data, they want to keep access running as long as possible.

All in all, this is one of the worst security breaches ever, even if it is just because of the number of users affected. The response from Yahoo! does nothing to help and inspires no confidence in their ability to handle security issues.

I know, for a fact, that I am deleting my account as soon as I find out how to do so and will make that I avoid using their services as much as possible.

The Evangelist

This post was originally posted in the Workshare blog as The Security Evangelist.

Workshare Security Series

This is my first blog post in a new series on "security". I'll be discussing various aspects of security - how it affects you and how the team at Workshare handles the challenges around it through our products and operations.

The goal of the series is to help you understand how to better protect yourself and your clients, and to raise awareness of common issues and approaches to help resolve them. I'll also look into any relevant security events that may happen.

What is security?

To begin then - and this might sound a strange question - what is security?

This is a question that’s commonly asked and for which there are many different answers. When it comes to security on computer systems, we are talking about Information Security.

Information Security is based on the principle that data, whether customer, personal or business-related, needs to be stored and managed in a safe way. The industry-standard approach is built around three main concepts:

1. Confidentiality

Making sure that only authorized users have access to data.

2. Integrity

Ensuring data does not get corrupted, and keeping track of all modifications, including information about who modified what and when. In an ideal world, you will be able to go back to an exact point in time to identify this.

3. Availability

Having the most secure data store is of no use if the data is not there when you need it, so great care has to be taken to make sure the data is always available.

On top of information security requirements, there are also legal and compliance requirements that have to be considered as part of security.

So, now we’ve defined it, why do we need to worry about it?

From a personal point of view, you want to protect your privacy and make sure nobody can use your data for nefarious purposes, be it identity theft, fraud or any other crime.

As a business, you want to protect assets, both tangible and intangible, including business and customer-specific ones. Not only is it in the best interests of your firm to protect your client data, you will no doubt have contractual agreements and legal requirements to make sure you’re providing adequate security.

At Workshare, we’re constantly working to enable collaboration on files, while keeping data protected. Whether you’re an individual or a business, we help protect and manage data, while integrating that into normal document workflows of daily life.

In later posts, I’ll look further into how you can best achieve security and reduce risk to yourself and your business.

The Editor Wars - 21st Century Edition

For many years, there has been a split in the people who use Unix text editors and, with the turn of the decade, this has been extended to new ones, which seem to be taking over the developer world.

In case you don't know, I am talking about vi (these days, Vim) and Emacs.

Due to historical reasons, the Unix editors are not friendly to new users; they were created for text consoles, their shortcuts are completely non-standard and many concepts that we take for granted, such as windows or tabs, are hidden or unavailable in their user interface. As a consequence, they have a steep learning curve and require time investment just to get fluent with them and that knowledge does not normally transfer across to other programs.

The reason why these editors not only still exist, but are still actively supported and widely used, is that they are extremely flexible. Emacs, in particular, allows you to overwrite any behaviour via its embedded language, Lisp. Vim, while more limited, trades these limitations for a faster interface and lower footprint. For a long time, there was nothing as powerful as any of them.

Then Atom happened.

Atom comes from GitHub and it's designed from the ground-up to be an extensible editor. As opposed to Emacs, it embeds a really common language, JavaScript, and you can change its looks via CSS and HTML. In a very short time, it has gained capabilities that rival (or surpass, depends on who you ask) those of Emacs, while providing a modern interface and using standard conventions and key mappings. It is also multi-platform, supporting Windows, Linux and Mac OS.

Another problem that Emacs and Vim have is that they are designed as console text editors, everything is a text area. While that is extremely powerful, it also makes it really hard to to some things that we now take for granted, such as having drop-downs that stand out or different behaviours in panels.

On the other hand, the problem with Atom is that everything is, under the hood, a webpage. Atom embeds Electron, which is an embedded version of the Chromium engine, the same that powers Safari, Google Chrome and others. This makes it extensible and good-looking, but also slow, memory and power hungry, especially compared to Emacs and Vim (old-timers will long for the time when Emacs was considered a huge, bloated piece of software).

Despite of these issues, the usage of Atom has grown exponentially, the performance has improved and you can now find just about every plugin you want for it.

Not too long ago, Microsoft released an alternative to Atom, Visual Studio Code (VSCode for short). As Atom, VSCode is based on Electron but performs better because the VSCode API restricts what plugins can do.

After a couple of versions, Atom became fast enough for me and I started using it for all of my development, but something didn't feel right. I tried VSCode a few times but it just didn't feel right. I kept on trying and, when working with F# on the 1.4 version, VSCode finally clicked for me and I have now switched over.

This situation matches my experience with the classic Unix editors. My choice was Vim because it did feel right - it wasn't as powerful but it was good enough and didn't get in my way. Every time I used Emacs, I ended up frustrated, I just couldn't get it to feel right for me. I even used an Emacs clone for a while in preference to the real thing, Jasspa Microemacs, as that worked better for me.

So, the parallelism here is that VSCode is the new Vim, while Atom is the new Emacs. The differences are much smaller than before, you can't call VSCode a lightweight editor and the functionality is a lot closer, but the approach is similar.

As always, it's a trade-off.

Which one do you prefer and why? Feel free to leave a comment.

PS. I have not mentioned Sublime - it would be my ideal choice if it was open source but it is not and the number of plugins it supports is a fraction of what Atom and VSCode have.