The Security Evangelist, Lesson IV: Integrity continued...

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

Data integrity is quite a subject and couldn't be covered in one blog, so here's part ii. How to prove the integrity of your data...

Integrity guarantees do not prevent authorized modification of data, otherwise it would be impossible to add new versions of a document. What they do is provide users with ways of identifying all changes and who made them.

To be able to prove the integrity of your data you have to establish what the baseline is; the original data that you want to protect. A normal assumption is that the first version of a document is the canonical version and that any others that appear later are a modification of the original.

You then have to establish policies and controls around handling the data. This will ensure people understand how to manage it, whether it’s critical or not, and what to do when something goes wrong.

It is important to set permissions and tooling to prevent accidental modification and provide monitoring and metrics that enable you to assess events as they happen, depending on the criticality of the data in question.

There must be an established process to identify changes to data, including details about the changes themselves - the authors, modification times and any other data that will enable auditing. It should not be possible to modify data without leaving traces and common policy indicates that rolling back is impossible. If a version of a document is detected to be faulty, a new version undoing the mistake should be added and both kept for historical purposes.
Logs must be kept for as long as legally required and must include enough protection to prevent tampering. A common approach for this is to allow systems to generate logs that get exported to a separate system to prevent tampering and require a completely different set of permissions to access the logs. The ideal approach is to enable append-only logs, where data cannot be modified once it is in the log, no matter what level of permission you may have.

Finally, you must set up policies and processes to deal with unauthorized modification. This must not be an afterthought, in the event of a major breach you must be working on resolving the issue, not trying to understand how you can start investigating or who you should be talking to. All requirements should be established in advance, including communications, reporting and crisis management. The criticality of this last step cannot be underestimated, specially with new data protection legislation coming out, such as the GDPR, which requires timely reporting to customers and the authorities on any data breaches.

The importance of data integrity must be fully understood across a business. A corrupt or incorrectly modified document in circulation will not only incur reputational loss, it may also cause large amounts of financial pain in the form of legal cases and external audits.
Once policies and controls are in place, it becomes a matter of regularly reviewing and verifying them and taking any learnings from events and the way they are handled, whether successful or not.

In later posts, we will look at how blockchain can help create logs that are open and tamper-proof.

How to handle a support request: GitLab

The same way as I complain when someone does a lousy job, I want to give props to a company that seems to do it just right.

I am a GitLab user by choice. A while ago I moved most of my repositories there. The initial reason for the move was that, at the time, GitHub did not allow private repositories for free users and I like to keep my projects private until I am ready to publish them.

Since then, I have not found a reason to move, it just works. Admittedly, I am a very light user, but I like what I see. As a security professional, I also like that they offer an on-premises solution and an open source one so you can fix issues if you find them.

A couple of days ago I got a GitLab invitation to a group I had not heard about. It sounded suspicious but I am currently waiting for a couple of technical tests to come my way and thought that it could be related and, in any case, there should be nothing that could attack my computer on the locked-down browser I use, so I accepted.

When I got into the group, there were over 180 users in there, but no other content. I dug out a bit more and all of the users had joined in the last 3 or 4 hours or were pending. At this point, I was sure that there was something wrong with this group, so I left and went to report it.

I sent an email to the support email (readily available in multiple places) and an email address that I guessed for the security team (no bounce, so it may actually have reached them) and got a receipt notification at 15:24. So far, so good.

At 16:34 I got a confirmation email to let me know that someone was looking into the reported issue.

At 16:38 got another confirmation email telling me that the user that invited me had been identified as a spammer and was being dealt with and a link referring to a ticket about a similar issue.

So, in less than 1:30 they read my report, performed an investigation and sent me a reply with the actions they were taking. Colour me impressed, specially because this is for a free account and I have never paid them a penny.

I have seen GitLab representatives in multiple technical sites. Whenever someone mentions any issue with the product, there will be one asking for more details and I have not seem them been rude or anything like that.

They have also been increasing the capabilities of the free version of the software as people requested them, while keeping obviously enterprise-related features for the paid one.

I was obviously pre-disposed to use them professionally before but now, after this experience, I am even keener. If they provide this level of support and responsiveness for free customers, I expect them to be great for paying ones.

Well done GitLab!

Choosing Your Next Programming Language

It's the time for New Year resolutions and many of you will choose to learn a new programming language.

As with all choices, there are many ways of deciding the one you want but, having done this a few times, this is the criteria that I use.

First all, what do you want to achieve by learning a new language?

If you want to find a new job, your best bet is one of the really popular languages, which means something like JavaScript, Java, C#, Python, PHP or Ruby. These are not the most exciting languages but they will increase the possibility of getting a new job.

Of course, if you do know of a company you want to work for, just choose whatever stack they use. 

Also keep in mind that you are not only choosing a new programming language, you are also choosing a complete environment, with different tooling, libraries, documentation and even may require different OS. With the rise of Open Source and Free software, the cost should not be that much of an issue anymore and most licenses will allow you to use the software for free, but it's worth keeping an eye on.

If you would like to improve your development skills, there are two approaches that you can take, take a language that you already know and focusing in pushing the boundaries, EG. writing a complete new framework from scratch, try focusing on areas you do not normally do like doing embedded work if you normally do desktop applications or backend if you do frontend.

You can also choose a new language, using a different paradigm from what you normally use. For functional languages, you can use Haskell (pure, lazy evaluation), Scala (hybrid functional/oop on the JVM), F# (hybrid functional/oop on the CLR) or OCaml (hybrid functional/oop, compiled to native). For actor based systems, Erlang, Elixir (a more modern language on the Erlang VM, with improved libraries, tooling and macros), Scala. If object oriented is what you want, you could look at Ruby (dynamically typed, OO), Smalltalk (the daddy of OOP) or many others. If you want to program with statically typed languages, you can choose a new one (Go, Rust and Swift are popular) or go with statically typed languages that extend dynamic ones, such as Flow or TypeScript.

A different (and complimentary) way to choose a language is to decided what you want to do. Web development? Java, C#, Ruby, Python, PHP, JavaScript. Web APIs? The previous ones plus Go. Desktop application development? C#, Java, C++. Mobile applications? Swift for iOS, Java for Android, JavaScript for both (with Cordova/React Native), C# with Xamarin for both. System and command-line development? C, C++, Rust.

Again, you will often use the language that provides the frameworks and libraries that you need. If you want to do Windows desktop development, your best bet is C#, if you are doing Linux, probably C++ or C, etc.


In my experience, the most important thing about learning a new language is to find a project that you want to do and driving it to completion. Start small and then, once you have something completed, then add to it or find a more ambitious target.

Before someone asks, my chosen languages for early 2016 are a completely new language for me in an area I haven't done for a while, systems programming, for which I've chosen Rust and a language that I know but haven't done seriously for a while, JavaScript, both backend and frontend.

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.