This article is about finding the right strategy if you want to empower your business with cloud computing. It’s written for those of you who are still new to this topic and want to get a first sight through the dense cloud mystery. After reading you should have gained an orientation on how to start your first cloud project and a basic knowledge of the most important buzzwords of the industry.
It’s stormy outside
It’s been over a decade now that Amazon was stirring up the market with their web services and cloud computing is now more mainstream than ever. What for many people started with file-sharing- and backup-services like Dropbox or company internal NAS-systems, quickly transformed into a trending global topic. Why should you always upgrade local hardware and storage to stay competitive if you can have the same or even greater performance with shared resources, reduced costs and accessibility from everywhere?
Some understood that earlier than others and can already harvest the fruits from their work – and some, hopefully not you – should seriously think about protecting their house because the storm is not over yet! With the introduction of cloud gaming services like GeForce Now and the start of projects from the major players in the market, it starts to be clear that cloud computing is not just a hype, quite the reverse, anything seems to be possible and any upcoming business transformations should consider the opportunities of cloud computing for their needs. And who knows, maybe one day you can even sell your computing power as a part of the worldwide cloud like it’s been introduced by crypto-currency miners or solar tech companies?
Faster, Greater, Higher! The sky’s the limit!
So as enough time has passed that the first CTOs and CIOs can look back to their early experiences with moving to cloud services, we can wrap up some key facts if you’re still looking for a few good arguments which may convince you and your team for moving to the cloud.
Scalability with minor effort
Overwhelming traffic is not a show stopper anymore
Auto scaling infrastructure is auto money for your pocket!
Reduce the multi region infrastructure challenge
Cloud storage takes less risks than lost devices!
Stop to worry about underlying infrastructure security & maintenance
The disaster can come! Well proven Disaster Recovery Systems of great cloud providers are probably better than yours!
Speed & Performance
Increase your server-side performance on-demand as you go
Handle request peaks without costly overprovisioning your hardware
Reduced Costs = Greater Profit
Pay-as-you-go is better than buy-and-deprecate!
Financial advantages through transformation from CAPEX to OPEX
Makes your financial model a lot easier to plan and calculate
High chance to reduce your Time to Market
Emerging markets can perhaps make you even fly higher
Agility & User Experience
Stop your team from leaving their key competences
Increase your team performance with the latest collaboration tools
Satisfy your team by giving them a state-of-the-art feeling
Give more freedom for physical appearance
Less eWaste for deprecated hardware
Savings on power supply and emissions
And if you’re doing it right, you earn a lot of FLEXIBILITY which is nowadays more important than ever! Our technological environment changes so fast that you may be outdated before you finish your project – ok, probably not that fast – but you should be prepared! If your cloud provider can’t handle your SLA or gets outdated by himself, you may move on to a new provider but be aware: cloud providers want to keep you as a customer, for sure! How that may end up badly for you we’ll discuss in the next section.
Pitfalls you better leave for others
So if you’re convinced now by the advantages of the cloud, we reveal you some pain points where others have been stumbling, so keep them in mind and don’t make these mistakes again!
Readiness of Organization One of the greatest mistakes you can do while dreaming of your cloud project is to underestimate the know-how that is necessary to do the job right. Many teams stumbled over the fact that their ideas and plans were great but they forgot about the people who finally have to do the job. Your change management team also has to be aware that going to the cloud can also have a negative impact on other teams, so other teams in your company may start fighting against that change. Imagine for example your customers have now direct access to your order- and payment system, will your sales team like that? Your change can also impact your hierarchical structure and long cherished employees lose their major value for the team. So it’s probably likely that not everybody in your organization will like your project, be aware of that!
Readiness of Application It doesn’t matter if you’re developing a new or transforming an existing application, you have to keep the drawbacks in mind that can come along with cloud services. Too many technical leaders made the mistake of thinking a simple lift-and-shift strategy will work out and they had to learn by hard that some refactoring is always necessary. This can start by underestimating the threshold of your cloud provider, continuing with disregarding upcoming latency that destroys your user experience or dependency libraries that are restricted to be used in the cloud (rare, but reported). So you better make a new concept first and think from the very beginning which components can be reused in which way. Think about your build steps, your deployment, your test environment, your architecture, current infrastructure, previous concurrency issues, clusters you want to use – convince yourself first and not later!
Data Privacy & Compliance Especially with the release of the new data privacy regulations from 2018, many companies got messed up and reported big question marks on how to continue with their services. So you can be lucky to start your cloud project after this disrupting wave but you shouldn’t think that the current data privacy agreements will last forever, this was rather just the beginning of regulations that were missed since the beginning of our digital lifestyle. Data privacy for your customers and data protection imposed by your company compliance will harden your way to the cloud – that’s for sure!
Remember your Business Idea! It doesn’t matter if you start a new project or lift some existing functionality to the cloud, if it creates advantages, any motivated employee will create further and further ideas how to improve and scale the impact of your cloud movement. So if you impress your environment, you can likely be sure that it doesn’t take a long time until the first ideas from other teams or team members land on your desk! So keep your primary business goals in mind and finish them first before you start working on other issues. If you’re a technical leader or you’re the one who pushes the cloud movement forward, take the advice to reflect yourself frequently and check if the tasks that you’ve created also have a value to your business. Too many become starry-eyed for cloud transformations and lift them to a holy-grail, which it isn’t for sure! So think twice if the current steps are really necessary and profitable for you and your team!
Vendor Lock-In It’s too sad to be true but in reality it’s a fact. We have two strongly diverging mindsets in our industry. There are the ones who believe everything should be free and open sourced and the others try to catch you in their cage and won’t ever let you go. So you got to be aware of the fact that it’s common under cloud providers that they will try to trap you with special offers, extra support, personal training sessions and individual implementation opportunities just to keep you as a customer as long as possible. So if you start to implement services based on proprietary interfaces it will be harder for you to relocate your codebase one day. Or if you build up a special knowledge customized to their services, you may wake up one day and realize that this knowledge is now worthless. So in other words, if their ship goes down, you’ll go down too! So be aware to avoid a vendor lock-in as much as you can!
Cloud Provider Evaluation Especially those who are new to this topic may stumble across a thing called SLA (Service Level Agreement) which defines the contract you sign with your cloud provider. If you don’t know exactly what it contains and where the borders of your cooperation are, you may run into trouble sooner or later. So it’s a good advice to get somebody for your team who was able to collect some experience in the cloud environment before and protects you from making the same mistakes that others did. It’s not about missing some contract details, it’s more about finding the right values and parameters that fit to your application and finally to your business case. As long as your project works fine you’ll probably never get in touch with your SLA that much, but once you got your customers or your boss in your neck, if there is an unexpected downtime, drastically rising costs due to a miss-configuration or a security lack, or even a disaster with a never ending recovery time, you will understand why knowing your SLA details is important. Take it as a good advice, especially at the beginning of your cooperation, that measurement and control is better than relying on trust. So the job is to monitor and measure as much as you can until you get a good feeling of what’s going on and how much responsibility you can take for it. Expect the unexpected!
Your guide through the jungle
So as far as you are familiar with the greatest advantages and biggest show stoppers now, we can start to create a cloud strategy that fits to your needs. Get your weapons locked and loaded and follow me through the jungle!
What do you want to create?
Remember your business goals and remember how others have lost the trail and you don’t want that the same happens to you, right? So define your project and especially your project scope precisely. What do you want to create? What is what you want to offer to your customer? Who is your customer and what do they really need? Think about your use-cases and match them accordingly. To make it a little bit more confusing, maybe you’ve heard about XaaS or *aaS which is one of the most blown up cloud buzzwords ever! What had once started with Software as a Service (SaaS), which basically means software delivered by cloud services, later transformed into a term that is almost used for any kind of service. Firewall as a Service, Payment as a Service, Analytics as a Service and even non- technological ones. But the idea behind the services-oriented model is great! So if you want to market your later product right, think in terms of services! Remember how you changed your business model from CAPEX to OPEX and your future customers want to have that too! They don’t want to buy a product, they have a goal and they are looking for the right service to reach their target as fast and as best as they can. And that’s a fact for any kind of customer. So you are serving them your best to let them reach their best! They other way around you have to think of the same terms for your goals. But this is a matter of your skills, compliance and amount of responsibility you want to share. Netflix for example thought they could fly high and even higher, so they built up their own infrastructure and data centers until they had to realize that they can never get this job done any better than Amazon does. From that point on they focus on what they really want to do: delivering awesome series! So think about the services you want to deliver, what kind of services would be a help for you, short term and long term! Imagine your project growth stages from time to time, where is your starting point and where do you finally want to get and find a match with a cloud provider that has all the abilities you need for your scale.
If you’re willing to create services that are mainly for corporate users, think of a private cloud with outsourced hosting facilities which is in fact technically nothing else than a restricted public cloud for your private usage. If your compliance or your business case doesn’t force you to keep your data in-house, guard it with a virtual private network access (VPN) and you are ready to go. If you once need to open some services for public usage you can still transform it to a hybrid cloud by removing the according restrictions or routing it through a public cloud.
To not leave you unarmed, we’ve created a checklist that you may consider at the start of your cloud project. Critics are always welcome, if you’ve noticed some missing points or made different experiences throughout the years, let us know and write it in the comments down below!
What’s my business goal? Which requirements does it take?
How can I accelerate my time to market? Is the market ready for my concept?
How ready is my application or existing architecture?
Is there a need for refactoring? Does it also consider potential cloud
drawbacks like latency, downtime, noisy neighbours, migration, licenses and so on?
How ready is my organization and team? Who can do the job?
Will it change my business model? Does it disrupt my team?
Which restrictions do exist? Compliance? Security? Data privacy policies?
Where do I need help in terms of services? Long term? Short term?
Where do I want to grow? How much responsibility can I share?
Does the SLA match my requirements? How about Disaster Recovery?
Do the project requirements match my budget? Can it be done at the given time?
And as a final word: Don’t over engineer and don’t over manage it all! Keep it simple and straightforward and learn from your mistakes. Never lay back, be proactive, expect the unexpected and create your plan b – than you’re prepared for whatever it takes 😀
Through networking and the Internet, more and more people can share their opinions and spread news. This has positive and negative consequences. On the one hand, it is much easier to get the news you want and to publish it. On the other hand it is relatively easy to influence other users. An insight into the search on Google Trends for the term ‘fake news’ shows the current relevance. Since October 2016, people are increasingly searching for the term. There are individual rises in search peeks which can probably be linked to various events. We can expect to come into contact with fake news every day.
In 2020 many things are different. People work and study from home, wear face masks and are facing restrictions in their fundamental rights. These measures and restrictions were taken to bring the global pandemic under control. More than 800.000 people have died as a result of Covid-19 (SARS-CoV-2) (25.08.2020).
“Let’s build an app for it” is the simple answer for many things. Therefore, it is no surprise that a lot of people asked for an app to fight Covid-19. In Germany, the “Corona Warn App” was published on June 16, 2020  . Controversial topics being discussed in the public were:
How does such an app work?
What are the benefits?
Will the number of false positives become too high?
How secure is it?
Does this restrict privacy?
Today, that the app is available for 2 months and has been downloaded more than 17.5 million times. This might be a good time to give answers to the questions above.
Everyone interacts with it, often on a daily basis, everyone is part of it and everyone will suffer from the consequences of a crisis hitting the system, but only few reap the benefits. The financial system has become huge and ominous, it is hard to understand how it works or even fully comprehend it. This article shall give a little insight on the financial system and its shortcomings.
Part 1 of this series discussed how AI technology can be used for good or evil. But what if the AI itself becomes an attack vector? Could an attacker use my models against me? Also, what’s the worst that could happen? Welcome to the domain of adversarial AI!
Who hasn’t seen a cinema production in which an AI-based robot threatens individual people or the entire human race? It is in the stars when or if such a technology can really be developed. With this series of blog entries we want to point out that AI does not need robots to cause damage. Already today, AI is used in harmful ways and we should be aware that every progress in AI technology has a downside, especially if we, without considering the possible consequences, make results openly available and thus offer everyone the chance to use the technological advances for their own benefit.
This first part of the blog series addresses the dual-use character of today’s AI by showing possible applications of AI in the lifetime of cyberattacks. The defensive possibilities are briefly presented, but the focus is on the offensive, i.e. the possibilities that AI offers attackers to execute cyberattacks more intelligently and automatically. Based on this, a technology that could become a major threat is investigated more closely: Deepfakes. I’ll give you an insight into how this technology works, the threats it poses and why people in general can be quickly influenced by such misinformation. New AI technologies can not only be used for attacks, but also the AI itself can be manipulated, which can cause great damage, especially in systems where AI makes decisions.. This topic is covered in part 2 of the blog series.
Let me start with a story. My first contact with GDPR (general data protection regulation) and the topic of information security was during my bachelor throughout an app project. We had set ourselves the goal of uploading the app to Google Play Store by the end of the semester and were thus inevitably confronted with the data protection and privacy topic, which was still relatively fresh at the time. Since we had no previous experience and background knowledge in this area, we were rather intimidated by the available information and very vague wording in correlation with GDPR. The intrinsic desire to take care of personal and sensitive data was rather absent and overshadowed by the fear of doing something wrong and experiencing legal consequences. When we turned to professors and lawyers at the university, who were (in theory) responsible for the topic of GDPR and information security, the responses were comparable to the game “hot potato”. Everyone we approached tossed the hot potato (aka GDPR) to the next person by saying something along the lines of “Ah yes, I think Mr. X would be more suitable for that”. In the end, we kind of patched together a data privacy declaration and implemented suitable protective measures, which was okay for the time being, but not particularly good and worthwhile. Overall, it left a rather unsatisfactory feeling and aftertaste.
The combination of founding my own Startup and attending the lecture “Secure Systems” during my masters made me rekindle with that topic again and I decided to take matters into my own hand and shine a new light on this rather unattractive and dry, but also very important and meaningful subject.
Therefore – with this blog entry – I’m hoping to provide you with a more practical and satisfactory approach to information security and GDPR. I will answer questions like “Why should I even strive for GDPR compliance or security in general?” and “What can I – as a programmer – do to achieve information security?”. Furthermore I will explain terms like Privacy By Design, Privacy By Default and Security By Design. This guide is addressed to all those who want to gain a better understanding of this topic in general, as well as start-ups, smaller companies or freelancers who are looking for specific information to implement this topic in their own applications with a focus on inexpensive but effective measures. However, it should not be considered as a complete and sufficient solution for information security.
My forecast for the future is: In the future we will talk much more about information security insteadoftalking about IT security and data protection / GDPRseparately!
Eric Weis (CISO and auditor of ISO/IEC ISO27001)
With this fitting quote in the back of our minds, let’s dive right into it. 🤿
Why should you even strive for GDPR compliance?
Depending on the severity of the violation, fines of up to €10 million or 2% of the total annual turnover of the previous business year, or respective €20 million or 4% for the higher severity level, may be imposed if your organisation violates data privacy guidelines. The respective frame that is chosen is the one which is higher (GDPR Article 83, section 4 and 5). For example, Google (Sweden) was fined €7 million in March 2020 for failing to remove personal information from various individuals who had requested exclusion from Google search results. An Italian telephone and network operator (TIM SpA) was hit even harder, being fined €27 million in January. The reason for this was several legal violations in marketing and advertising campaigns. Unsolicited calls were made, people were entered into competitions without consent and in one case, a person was called 155 times after requesting exclusion from calls. Even in law-abiding Germany there was a high penalty in December 2019. 1&1 Telekom was fined €9 million because anyone could get complete access to a person’s data as long as they simply knew that person’s date of birth and name.
The vagueness and individuality of GDPR
Upon reading statements and guidelines of the GDPR, such as the following excerpt of Article 32, which targets the Security of processing, one often has more questions and uncertainties than before.
Art. 32 (1): „Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk…”.
All wordings, components and safety measures that vary according to context and organization, are color highlighted. Only once you start breaking down the separate parts and enrich them with background knowledge from information security, a greater picture starts to form. With that being said, here’s my breakdown of the separate parts:
“…the state of the art…”
Mainly refers to technology. It makes sense: the safety and security measures you implement today might be outdated in 3-5 years. Technology and software have a fast pace, which should be reflected and reviewed in your infrastructure and design choices.
“…nature, scope, context and purposes of processing…”
Depending in which field your organization is operating and what kind of sensitive information you’re processing the needed safety measures vary a lot. The how and where of data processing are also really important. Do you dispose of all data completely independently or are third parties involved? Do you process highly sensitive information like racial and ethnic background, political opinions or religious beliefs, health data or information regards the sexual life or orientation of your users.
“…risk of varying likelihood and severity for the rights and freedoms of natural persons…” “…appropriate technical and organizational measures…” “…level of security appropriate to the risk…”.
This is basically risk management. If you’re striving for ISO 27001 compliance this is handled by your Risk Treatment Plan (RTP) and your Statement of Applicability (SoA). There are different approaches for application thread modeling. One popular and widespread one is using STRIDE and DREAD. It’s about analyzing which vulnerabilities or weaknesses in your infrastructure / architecture lead to risks of violating the core pillars of information security. Confidentiality, Integrity and Availability.
Depending on your background knowledge and the field you’re specialized in, even in those more detailed explanations there might be a lot of unknown terms for you. I’ll try to provide you with some basic knowledge in the following paragraphs.
Before taking a closer look at core pillars of GDPR a quick side note about the LFDI: The LFDI is a German authority and roughly translates to “state commissioner for data protection and freedom of information”. It supervises and advises the public authorities of the country on data protection and information security issues. One of the tasks of the LFDI is to impose fines on companies that violate data protection. In June 2020, for example, a fine of €1.2 million was imposed on the AOK, since they handled personal data incorrectly in regard to competitions during the timeframe from 2015 to 2019. Following an administrative fine, the LFDI also works with the organisation to improve the technical and organisational measures. However, if you’re looking for advice and specific recommendations, one must not have to wait until a fine is imposed on you. Instead, contact with the LFDI can also be proactively sought in order to receive advice and gain valuable insights. As part of my Startup, I did just that and will therefore incorporate advice and insights that have arisen throughout this cooperation. So, if I’ll say something along the lines of “the LFDI recommended using encryption at rest” you’ll know what and who I’m talking about.
The core pillars of GDPR
Hint: This is not an official classification; this is simply how I personally structured GDPR into different sections. It might help you too for forming a better understanding.
Prevent physical access to (personal) data. Ensure through appropriate infrastructure and technology that only authenticated users have access to data.
Safety measures might include:
no openly accessible databases
no default (admin) users for databases
As an organisation, one must clearly and comprehensively explain how data is processed, for what reason, for what purpose, etc. An awareness of who is responsible should be created. Am I? My company? A third-party company? Someone else? In general, you should be aware of what happens with the data and have an understanding of the complete flow of data in your system. The importance of a proper sense of responsibility was strongly emphasised by the LFDI’s technical manager.
Accountability also includes that a privacy statement is available, complete and easy to find.
👤 Individual Rights
You should respect and implement the user rights set out in the GDPR. Included is Privacy By Design and Privacy By Default. Ask yourself what the absolute minimum of data is you need in order for your service / product to work. Then try to stick to that. Work as data efficient and minimizing as possible. It’s also essential to only process data for as long as needed and delete it from your system once possible.
Content of the GDPR
Content of the EU General Data Protection Regulation
Rights of the data subject
Persons responsible for data processing and Third-Party Processors
Transfer of personal data to third countries or to international organisations
Independence of supervisory authorities
Cooperation and coherence
Remedies, liability and sanctions
Provisions relating to specific processing situations
Delegated acts and implementing acts
We’ll focus mainly on the developer and technical side of things, which are covered by the highlighted articles (5-50). Some key words and important components are shown in the visual below.
Putting the user at the centre
One cornerstone of the GDPR is that any processing of personal data is forbidden by default – unless the user has explicitly transmitted his consent. The consent of a user requires the clearly recognizable added value of the data processing. If the user gives his consent, it must be given voluntarily, explicitly and verifiably. According to the LFDI an opt-out or pop-up is not an effective consent! It is essential that the user can revoke this consent at any time and that his right to revoke must be pointed out directly at the time of consent. An example of the correct use of consent is asking the user for permission to use his e-mail address for sending him newsletters and updates. It’s key to adhere to the coupling prohibition, meaning that non-consent has no significant disadvantage for the user! Consent may only be mandatory if the disclosure of the data is absolutely necessary to provide the service.
To add on the point “Information obligation and transparency”: Data privacy statements must be worded in a way that minors and persons without legal capacity can understand them.
With the following examples of imposed fines, it should be made clear what one should not do:
Right to datadeletion
In October 2019, “Deutsches Wohnen” was sentenced to a €14 million fine for storing data in an archive system that offered no possibility to delete data at all. Their system therefore had confidential information on previous users who have long since stopped using the service.
Right to limitation of processing
Delivery Hero was fined just under €200,000 in Sept 2019 for failing to delete dormant customer information and continuing to send unsolicited marketing emails.
Right to protection of personal data
An insurance company in France was fined €180,000 in July 2019 because confidential data of other customers could be accessed simply by changing the number (user ID) at the end of the URL. The data disclosed included driving licences, registration cards and bank documents.
Privacy By Design
Too many entrepreneurs, in the interest of building the product as quickly as possible, think that security is a “freeze all the code, do an assessment, and write all the policies” project they can do later. It isn’t.Think about security from the very beginning. It’s actually not that hard to anticipate what needs you’ll have to deal with in the future.
Michael Borohovski – Cyber Security Expert
Data protection must be included from the beginning of the design and development of an app. You should NOT develop the app, add functionality, acquire customers and then at some point – possibly when there are already millions of users on the system – realize “Oh, maybe I should take a look at privacy and information security”. This approach has been possible in the past, however since GDPR a bare minimum of information security is required by law. All in all, it is anyway much easier and more sustainable to develop a safety mindset and culture from the very beginning and then to continuously improve and expand it as you grow.
Risk Assessment has some overlapping points with Security By Design, however since Privacy By Design can also be viewed as Data Protection By Design this overlap is unavoidable and reasonable. This includes the different likelihood of occurrence and the damage potentials of the risks associated with the processing of data. Information security and data protection are simply closely tied together, as already depicted in the quote at the beginning. Another key element that should be targeted by a thorough analysis is data minimization. During data processing, only as much personal data should be collected as is absolutely necessary for the respective application. Authentication, anonymisation and pseudonymisation and encryption of data are all safety measures that are actually explicitly listed and specified in the GDPR. According to LFDI using TLS 1.2 or above in transit is mandatory and additionally encrypting your data at rest is highly recommended. The reason being for the latter that servers are often located with a provider. If, for example, technical errors or the termination of the contract should occur, there shouldn’t be any resulting problems if your data is encrypted. Therefore the risk of violating confidentiality is reduced.
In summary the system should be conceptualized and developed so that maintenance of user rights, such as access, deletion and correction of data are addressed from the very beginning.
Privacy By Default
When using an application, the preconfigured settings must always offer the highest possible security and data protection. Only by opting out or manual configuration of the user can the security or data protection be reduced in order to obtain simplifications or advantages regarding usability. The aim of this directive is to protect the less technologically inclined users, who are not able to adjust their data protection settings themselves.
Users should therefore be able to decide for themselves what data they make available to companies beyond what is necessary.
Airbnb has a really good and interesting approach in my opinion. In their mobile App they list all services and tools they use in their privacy section and you can decide which one to enable or disable. There’s only 4 SDKs that are strictly necessary and therefore can’t be disabled (Braintree, Facebook, Google Maps and Google reCAPTCHA).
Security By Design
Applications without security architecture are as bridges constructed without finite element analysis and wind tunnel testing. Sure, they look like bridges, but they will fall down at the first flutter of a butterfly’s wings. The need for application security in the form of security architecture is every bit as great as in building or bridge construction.”
As already mentioned earlier, a proper implementation of information security is now basically mandatory and legally required due to GDPR.
That this is unfortunately not (yet) always the case is depicted by the €123 million fine Marriott received in July 2019. After acquiring its competitor Starwood, Marriott discovered Starwood’s central reservation database had been hacked. This included 5 million unencrypted passwords and 8 million credit card records. The breach dated back to 2014 but was not discovered until November 2018. In total about 30 million EU residents were affected.
I hope that the violations and respective fines listed in this blog have already given you some insight into what you should NOT do if you intend to correctly apply privacy and information security in your company and processes. However since I always feel that illustrative examples provide a lot of benefit in understanding a complex topic, this is exactly what we’ll do now to deepen the understanding. Guided by the core pillars of information security, we’ll look at some concrete measures one can implement to increase security and robustness.
The core pillars of information security
In short: Sensitive or personal data should not be disclosed to outsiders. Countermeasures include (strong) passwords, access control lists and authentication procedures. It’s beneficial to use encryption so information that may be accessed despite the previous controls is still protected.
Integrity means on the one hand that data may not be changed from the outside and manipulation is impossible, but on the other hand it also means protection against unintentional changes, such as through user error or data loss due to a system error. Changes should only be made by authorized persons. In short: the correctness and completeness of data must be guaranteed.Countermeasures include access controls and strict authentication. Administrative controls such as separation of duties and training are also beneficial.
An example of an availability violation is the loss of data through malware. Actually, most threats for availability are non-malicious in nature and include hardware failures, unscheduled software downtime and network bandwidth issues.
Countermeasures include redundant systems in separate physical locations and backing up data. Especially Systems that have a high requirement for continuous uptime should have significant hardware redundancy with backup servers and data storage immediately available.
Additional principles are:
Authentication ⇒ Recipient must be able to determine the origin of the message
Non-Repudiation ⇒ The authorship of a message/action must not be deniable
Anonymity ⇒ Protection of the confidentiality of the identity
Accountability ⇒ Ensuring that subjects can be assigned to their actions
Auditability ⇒ Ensuring that previous system states can be reconstructed and processes can be traced
Security – Practical Measures
In this example, specifically Event Loop Monitoring.
If the application server is under heavy load, it may not be able to serve newly arriving users. By monitoring the status of your application it can be checked whether certain thresholds are exceeded, such as response time, memory usage, CPU load or in this case the lag of the memory loop in seconds.
If a predefined threshold is reached, new requests can be blocked and a 503 server too busy response sent. This way the application remains responsive at least for current sessions.
Safety measures against Brute Forcing
Attackers could use brute forcing to obtain account passwords and thus illegitimate access to user data. Certain routes (e.g. /login) can be explicitly protected against brute forcing. One possible measure could be using a rating limiter which specifies how many requests a specific IP address may make in a given period of time.
However, this measure would not work if the attacker uses multiple IPs for the attack. For this case an additional Account Lockout control should be used. In this case not the source IP address is checked, but the target account itself, i.e. in the attacked user account there is a counter for failed login attempts. Corresponding to that there are 3 variables: Lockout Threshold: number of failed attempts before the account is locked out Observation window: time period that these attempts must occur within Lockout duration: how long the account is locked out for
Application Activity Logging
Confidentiality, Integrity, Availability
Must have. Insufficient Logging & Monitoring is still in the OWASP Top 10. Not only can you detect errors at runtime, but attacks can be identified early or even prevented. As an advanced setup you can feed all your logs into a SIEM (Security Information and Event Management System) and enable Intrusion Detection / Prevention. So that you’re prepared and know what to do once an attack or breach is detected you should setup an Incident Response Plan.
Limit data flow
The information about the users is generally the most critical information an application has and despite that it’s not unheard of that applications transmit entire user objects back to the frontend. Including the full name, e-mail address, hashed password, birthdate and other sensitive information. Let’s say you’re developing a forum. A thread may have multiple messages / entries of different users. For an entry of another user to display correctly the only thing the frontend needs to know and see are the user id, his username, his avatar, maybe his total amount of submissions / moderator status and obviously the message itself. But there’s no need for your backend to send anything else. So what you can and should do is sanitize objects before sending them to the client.
Keep your packages and dependencies up to date
Confidentiality, Integrity, Availability
Using components with known vulnerabilities is part of the OWASP Top 10 as well.
Security of your application depends directly on how secure the third-party packages you use in your application are. Therefore, it is important to keep your packages up-to-date. OWASP – CheatSheetSeries
The reasons why this affects all three parts of the CIA-triad is because it depends entirely on the libraries and frameworks you use. Whatever vulnerabilities and risks might be in any of the components you use, your application automatically has them too. One tool I find really helpful for keeping track of used packages and their respective security & status is Dependabot. You can link your GitHub project to it and it automatically checks for updates and bug fixes in the libraries you use. For everything it finds, a pull request is created. Severe fixes are for example highlighted by a “Security” tag (as seen in the figure below).
Stay clear of unfavourable regexes
Most Regular Expressions can reach extreme situations that cause them to work very slowly (exponential in relation to input size). Therefore, an attacker can use regular expressions to crash an application by performing a Regular expression Denial of Service (ReDoS). There are some tools to check if a regex has a potential for causing denial of service. One example is vuln-regex-detector. Besides that, applying input validation in general is already a good and meaningful approach.
Security Linters and Code Checking
Confidentiality, Integrity, Availability
There’s a big overlap between secure code and good software design. The theory that applies here is: the cleaner and stricter your code is, the fewer bugs you have and the more readability you achieve. By using linters and code checking you can find bugs BEFORE they happen and therefore also need less time for testing. Imagine the advantage of detecting an error while writing the code vs detecting the same error only now it’s once the application is already deployed to production.
Another advantage gained is that you’ve standardized code if all your team members use the same guidelines and rules. This eliminates discussing about stylistic issues and enables you to focus on more meaningful topics like architectural decisions or security issues.
The secure principle Reluctance to Trust applies here. When building an application, you should always anticipate malformed input from unknown users. Even if users are known, they are an easy target to social engineering attacks, making them therefore potential threats to a system. With correct input validation widespread and popular attacks like (SQL) Injection or XSS can be prevented.
Any integer between -2 billion and 2 billion is seldom a good representation of anything.
One interesting approach to input validation is using Domain Primitives. For example, instead of using a string as type for a username you define a class called UserName. This class has all domain rules related to a username bundled in itself, e.g. minimum and maximum lengths, allowed characters, etc. Therefore, if the value exists, its automatically valid!
Transactions in NoSQL Databases
Say you’re using MongoDB as database. By default, it doesn’t support transactions and therefore the ACID principles are not given. If you do have any logic chains in your application that consist of more than one write command, you’re in trouble. It might happen that your server restarts during one of those logic chains and only a fraction of many dependent writes is executed. As a result, you’d end up with corrupted and incorrect data in your database. Depending on the context of your application and the severity of that risk, you should either consider switching to a database that innately supports the all or nothing principle – transactions -, or setup transactions for your MongoDB database. This can be done since version 4.0 by setting up a replica set. The opinion of the LFDI towards this topic is actually quite strict and limiting. Their advice is to always use a “proper” database, like PostgreSQL. Their argumentation is that only sequential databases can guarantee mathematical correctness and thus integrity of the data. However, it’s totally reasonable that you might chose a “non-optimal” database for your projects for reasons like being lean or simply being more experienced with it. This is absolutely valid. You should still try to get the best possible security with the choice you have made. By doing so you probably end up with a higher security level anyways than when you’d have chosen the theoretically best fit with which you’ve no or limited experience.
The statement of the LFDI being: “Only if a lack of technology leads to a protection goal being violated, then it can become a problem”. In other words: if a violation or a breach could’ve been prevented if you’d have chosen another technology, like SQL instead of a NoSQL, only then there might be repercussions.
Prevent data (e.g. IP Address) leakage
This goes hand in hand with being conscious about data flow in your application. Chances are high that you carelessly give data of your users to strangers. The easiest example is embedding an image into your app which is hosted by someone else. If the image is not physically located within your own infrastructure, any external hoster could read the IP addresses of your users accessing said embedded image. Another popular example is using SDKs. The very polarizing opinion of the LFDI is that one would have to forego using ANY third-party components or libraries, if the objective pursued is to be as data protection friendly and correct as possible. However, the LFDI also realizes that this is contrary to the entire open source movement and ultimately simply not feasible. If you’d follow that guideline, you would have to constantly reinvent the wheel as a developer. They key takeaway is Reluctance to Trustagain. Be really conscious about which libraries or SDKs you’re adding to your project. If you want to be really sure, you should check each library for potential data leakage before adding them. And if you’re planning on adding something like Facebook or Google SDK, ask yourself if it’s worth it. Are your users okay with their data being shared? Does the benefit outweigh the negative? At the end of the day there’s always a business model behind something. Facebook and Google are not offering their SDKs for free, because they are such kind hearted people. They want to gather as much data as possible. And that’s exactly what happens once you add those SDKs to your project. Be aware of that.
GDPR and information security can be a daunting task and overwhelm you on first approach. I totally get it, since I’ve been there and quite frankly still am. However, I think it is essential to recognize the importance of the issue. In the end, it is not just a matter of taking action out of fear of fines, but of actually seeing the bigger picture. First of you establish trust. If you’re honest and authentic your users and customers will definitely notice and appreciate it. Secondly, the complexity of software systems is constantly increasing and connectivity between systems and devices is growing. In combination with weaknesses due to errors in requirements, architecture, design, implementation, operation and organization this could break your neck financially if you don’t take safety and security into account from the start. According to the IBM System Science Institute the relative cost of fixing defects can be up to 100 times higher in production than in the design & planning phase (as seen in the figure below).
Security incidents regularly affect companies of all sizes, often putting them on public display and causing irreversible damage to the reputation of the companies involved. To add on this, our society is more technologically reliant than ever before and there is no sign that this trend will slow.
If you plan on your software existing for more than 5 years, start developing a data and information security mindset. Be mindful about the tools you use, where data flows in your application and learn to think ahead. Ask yourself what risks or vulnerabilities might arise and what inconsistencies could appear. Be careful, anticipatory and conscientious. But don’t overdo it, after all it’s about your (and your companies) priorities. Decide what is best for you right now and plan a little into the future. But there’s no need to try and anticipate everything that might happen and to build a Fort Knox infrastructure right from the start. Information security should be seen as continuous process in which you iterate and evolve in many small and incremental steps. I truly hope this blog helps you get started on your way and gives you some insight into the possibilities and opportunities. As another help to get you started, I attached a small cheat sheet and some useful resources.
Smart thermostats, lamps, sockets, and many other devices are no longer part of any futuristic movies. These items can be found in most households, at least in parts, whether in Europe, America, or Asia. A trend that affects the entire globe and is currently gaining ground, especially in industrialized countries. It seems to be obvious that there is no way around a smart home in the future. Questions that arise are: whether these devices are safe, currently gaining ground, or can they be safe at all, and what practices are in place to secure them?
Anfang 2021 soll die elektronische Patientenakte (ePA) starten. Damit wird es möglich sein, alle Gesundheitsdaten (Befunde, Diagnosen, Behandlungsmaßnahmen, Arztbriefe, etc.) zentral zu speichern. Patienten bekommen so einen zentralen Überblick über all ihre bei verschiedenen Ärzten erfassten Daten, und sind in der Lage, diese Informationen mit bestimmten Ärzten zu teilen. So wird der Datenaustausch zwischen Ärzten, Krankenhäusern, Apotheken etc. stark vereinfacht, und das manuelle Transportieren von z.B. Arztbriefen oder Röntgenbildern vom einen Arzt zum Anderen gehört der Vergangenheit an. Die Nutzung ist freiwillig und die Daten sind selbstverständlich sicher verwahrt.
Soweit die Versprechungen des Gesundheitsministeriums.
In der bisherigen Umsetzung zeigen sich allerdings fundamentale Schwächen, sowohl im Rollout der Infrastruktur, als auch bei der ePA selbst.