{"id":3221,"date":"2018-03-25T15:51:15","date_gmt":"2018-03-25T13:51:15","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=3221"},"modified":"2023-06-09T14:13:04","modified_gmt":"2023-06-09T12:13:04","slug":"security-in-a-saas-startup-and-todays-security-issues-with-devops","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/25\/security-in-a-saas-startup-and-todays-security-issues-with-devops\/","title":{"rendered":"Security in a SaaS startup and today’s security issues with DevOps"},"content":{"rendered":"

Motivation<\/h1>\n

Facing security in a company nowadays is a big job: it starts with a backup strategy ensuring the business continuation, plans for recovery after major breakdowns, ensuring physical security (entrance control, lock-pads, safes), screening of potential employees, monitoring servers, applications and workstations, training the employees in security issues and policies and does not even end with a proper patch management or in case of software development secure coding. As we see using a safe password ([10] explains safe passwords) and the hope of not being caught by the next ransom attack is not enough. Security is a combination of organizational, technical and physical measurements.
\n
\nAnother view on security is the technical one, looking at algorithms like RSA, secure hash functions, protocols like tsl\/ssl and the PKI etc. We have good tools, but if we look at our technology stack it is still impossible to create a 100% secure system nowadays. There are security breaches in each layer, starting down at the hardware, e.g. a Qualcomm Chip [11], going up to the operating system (e.g. PtH [12]) up to the application using a lot of third party code. A secure system must not use any unsecure third party or legacy code and must not rely on any unsecure other systems – so we would have to start from scratch.<\/p>\n

We cannot assure a 100% secure system or even a 100% secure company, but we can keep the risk down at an acceptable minimum. This is where economics plays in – taking security measurements costs money and we must decide how much money (or time – but time is money again) we spend on security.<\/p>\n

 <\/em>\u201cBasically, you’re either dealing with Mossad or not-Mossad [the Israeli CIA]. <\/em>If your [opponent] is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from <\/em>ChEaPestPAiNPi11s@virus-basket.biz.ru<\/em><\/a>. If your [opponent] is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT.\u201d<\/em><\/p>\n

James Mickens [4]<\/p>\n

A good overview of what can be done today gives Google’s whitepaper on their security management [13] – they do a lot, starting with dedicated hardware encryption and signing. The security in a company is also addressed by the ISO 2700X standard, consisting of a lot of requirements and over a hundred measurements to be taken. But where to start?<\/p>\n

In this article, we look at security from a startups point of view: what do we need to do in an early stage, developing in our garage, without too much effort. We will take a special look at the DevOps toolchain, as its automation leads to new security issues.<\/p>\n

DevOps? DevOps is the merge of development and operations with the goal to test, build and release software fast, frequently and reliable. This leads to an automated toolchain, in which a single change in code by a programmer can result in a new production release (Continuous Integration, Continuous Delivery). A programmer now has impact on a productive system and needs to think about configuring and running the software securely.<\/p>\n

Scenario: Working in the living room<\/h1>\n

To take a closer look at the security in a small company our scenario will be a SaaS startup, just founded, without any customers yet. Figure 1 gives an overview \u2013 making no claim to be exhaustive \u2013 of the minimal infrastructure we will need.<\/p>\n

\"\"<\/a>
Example of an early stage infrastructure \u2013 maybe more tools and systems than one would think<\/figcaption><\/figure>\n

As we can see we need a whole bunch of software to communicate, document and organize our work and code. Looking at this infrastructure from a network view we can see a lot of interaction between the different systems. We must handle a lot of accounts, secure communication and especially take care of the infrastructure running in our own cloud (back office, continuous integration, continuous delivery, our own API service), see figure 2.<\/p>\n

\"\"<\/a>
Example on an early stage infrastructure network view \u2013 there are more systems we interact with than one would probably think. | CI \u2013 Continuous Integration, VPC \u2013 Virtual Private Cloud, PW \u2013 Password<\/figcaption><\/figure>\n

Keep track of your tools and systems<\/h1>\n

To manage all your tools and systems I suggest to introduce something like a company board or system overview at a central place, reachable by every employee. It could be a word document, but better a wiki page, a one-pager-website only available to employees. It should contain a list of all systems and tools with a description what there are for and when to be used. This information is something like a small policy one would write in a larger company, e.g. \u2018place documentation in this wiki\u2019 and \u2018place invoices in that cloud\u2019. Some security experts might argue that an attacker could get to much information out of such a system overview, but I think that at this stage it\u2019s more important to keep track of all systems.<\/p>\n

Enforcing basic security<\/h1>\n

There are many easy and effective measurements to start with. Some will even sound too easy \/ boring \/ common sense to bother with, but they are still highly effective.<\/p>\n

We will not cover all of them in detail, but there are worth to be mentioned:<\/p>\n