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.