Most companies use perimeter security to secure their cooperate applications, services and data from attackers and unauthorised users. This approach includes a cooperate network, where clients, that are part of the network are able to access the applications. This includes attackers that got access to these networks. Additionally more applications are getting shifted from cooperate networks into the cloud and clients are getting more mobile from day to day. It’s getting increasingly difficult to trust or identify who and what should be allowed or trusted with access to their network. That means that setting up firewalls and other security mechanisms, securing the perimeter, is getting a real challenge and can result in very high costs.  
In order to adapt to the new requirements and to create a system that is compatible with the cloud- and the cooperate applications there is a new security approach: Zero Trust Security.
Die heutige Raumfahrt oder auch allgemein Raumfahrt ist ein sehr komplexes und vielschichtiges Thema. Nicht grundlos werden umgangssprachlich schwierige Themen als “Raketenwissenschaften” bezeichnet. Dieser Artikel möchte nicht die Raumfahrt in ihrer Gänze beschreiben sondern nur einen sehr kleinen Teil im Bereich der Sicherheit beleuchten. Hierfür wurden sich vor allem auf den Start einer Rakete und die Landung mit einer Raumkapsel konzentriert. Natürlich gibt es noch sehr viel mehr Sicherheitskonzepte in der Raumfahrt, als in diesem Artikel beschrieben werden. Zusätzlich werden nicht alle, sondern nur ein paar der Sicherheitssysteme angeschaut, da auch hier dauerhaft geforscht wird und was heute als Stand der Technik gilt morgen schon veraltet sein kann. Deshalb sind die hier beschriebenen Systeme auch keine puren Prototypen sondern eher etablierte Systeme, welche bereits seit Jahren im Einsatz sind, mit eventuellen Ausblicken auf zukünftige oder kürzlich neu erprobten Abwandlungen und Ideen.
Dieser Artikel ist außerdem nicht als Anleitung oder detailgetreue, vollständige Erklärung der hier beschriebenen Systeme aufzufassen, sondern soll lediglich einen Überblick über die Systeme schaffen und eventuell Lust machen sich mehr mit den Systemen und der Raumfahrt im allgemeinen zu beschäftigen.
Warum eigentlich Raketen?
Wenn man sich eine Weile mit der Raumfahrt beschäftigt stößt man schnell auf Ideen und Konzepte für verschiedene Systeme in den Weltraum, beziehungsweise in den Orbit zu gelangen. Hierbei finden sich immer wieder Ideen wie beispielsweise spaceelevator (spacelift), skyhooks oder space launch cannons. Viele dieser Systeme bieten eine auf Dauer kostengünstige alternative Fracht in den Orbit zu transportieren. Wir setzen immer noch global und fast ohne ausnahmen auf Raketen. Dabei haben Raketen eigentlich sehr viele Nachteile.
Offensichtlicher weise sind Raketen extrem Laut und der Treibstoff der beim Start verbrannt wird ist unter umständen sehr umweltschädlich. Raketen eignen sich dementsprechend nicht dafür mitten in der Stadt abgeschossen zu werden sondern es müssen extra riesen große Gebiete nur für die Starts freigeräumt werden. Außerdem sind Raketen sehr teuer. Geschätzte Preise für den Start einer Ariane 5 liegen bei 150-200 Millionen US-Dollar. Für die kleinere kommerzielle Falcon 9 immerhin noch bei etwa 62 Millionen US-Dollar. Dazu kommt noch, dass nur ein Bruchteil der Masse effektive Nutzlast ist. So wiegt eine Falcon 9 etwa 550 Tonnen. Aber nur etwa 22,8 Tonnen davon kommen am Ende im niedrigen Erdorbit (low earth orbit, kurz LEO) an. Das entspricht gerade einmal 4% der Gesamtmasse. Als vergleich ist das etwa, wie wenn man mit einem Großen LKW auf der Straße 100 kg Fracht transportieren würde. Und zur Fracht würden auch Fahrer und Kabine zählen. Ergänzend kommt noch dazu, dass wir den LKW nachdem wir am Ziel angekommen sind einfach wegschmeißen würden, da Raketen zumindest bisher nicht wieder verwendbar waren. Und selbst bei der Falcon 9 von SpaceX, welche zu teilen wieder verwendbar ist, wird immer noch ein relativ großer Teil weggeschmissen und die Einsparungen in den Kosten belaufen sich auch nur auf einen recht geringen Anteil. Als wäre das noch nicht genug ist ein Flug mit einer Rakete auch noch super gefährlich. Im Prinzip sitzt man auf einer fortlaufenden Explosion und hunderten Tonnen Sprengstoff. Wenn hierbei ein Fehler auftritt ist die Rakete meistens nicht mehr zu retten. Warum also nutzen wir immer noch Raketen? Die Antworten hierauf sind tatsächlich relativ einfach. Zuerst einmal sind Raketen einfach super schnell. Es werden gerade einmal so etwa 10 Minuten benötigt um in den Weltraum zu gelangen. Spricht man vom Weltraum ist sofort noch der Vorteil vorhanden, dass Raketen auch im Vakuum funktionieren. Sie bringen alles mit was sie zur Fortbewegung benötigen, im Gegensatz zu einem Flugzeug. Außerdem haben wir heute einfach ein sehr großes Wissen über Raketen und wie wir sie effektiv nutzen können. Sprich sie sind technologisch sehr gut machbar. Diese technologische Grundlage haben wir vor allem dem zweiten Weltkrieg und dem kalten Krieg zu verdanken, denn hier wurde im Spacerace natürlich auf Raketen gesetzt, da diese auch wunderbar als Waffe oder Langstreckenträger für Atombomben eingesetzt werden können. Kurz gesagt, dass wir heute Raketen verwenden ist vor allem Historisch so gewachsen.
Wie funktionieren Raktenstarts?
Der Start einer Rakete lässt sich grundlegend in mehrere Stufen unterteilen. Beim erreichen jeder dieser Stufen wird meist ein weiterer Teil des launchvehicles abgetrennt, sodass Die Rakete insgesamt an Gewicht verliert und leichter wird. Für was sollte man beispielsweise einen leeren Treibstofftank noch weiter mit sich herumschleppen, wenn dieser nicht mehr benötigt wird. Die obere Grafik zeigt einen normalen Ablauf beim Start einer Soyuz Rakete. Es wird aufgelistet, wann welcher Teil der Rakete abgetrennt wird und ungefähr die Zeit wann dies geschieht. Der Aufbau einer Soyuz Rakete mit den einzelnen Teilen, den sogenannten Stages, ist im unteren Bild zu sehen.
Launch Escape System (LES)
Wie bereits bei den Nachteilen von Rakete erwähnt, sind Raketen meist nicht mehr zu retten, wenn beim Start irgendetwas schief gehen sollte. Und da dies meist in einer sehr großen Explosion endet bleibt von der Rakete auch von der Fracht nicht sehr viel übrig. Deshalb wird an der Rakete wenn man die Fracht sichern möchte meist ein sogenanntes launch escape system installiert. Dieses LES ist im Prinzip eine oder mehrere weitere kleine Raketen, welche die Fracht von der Trägerrakete entfernen und in Sicherheit bringen sollen. Hierfür wird die Kapsel oder Fracht von der Trägerrakete entkoppelt, wie es eigentlich erst im Orbit passieren sollte und die Raketen des LES gezündet. Sobald die Raketen des LES ausgebrannt sind wird es ebenfalls von der Kapsel abgetrennt und die Kapsel kann mithilfe der für die Landung vorgesehenen Fallschirme sanft zu Boden gleiten.
Bei der Umsetzung des LES wird inzwischen auf zwei verschiedene Methoden gesetzt. Zum einen die klassische Tower Methode, bei der oben auf der Kapsel ein Tower installiert wir der das LES und auch ein paar andere Systeme enthält. Zum anderen gibt es das inzwischen von ein paar Fahrzeugen eingesetzte Pusher System, bei dem das LES in die Kapsel integriert ist.
Das klassische Tower-Konzept hat die Vorteile, dass es während des Fluges abgeworfen werden kann, sobald es nicht mehr gebraucht wird und somit die Last der Rakete verringert wird. Außerdem benötigt es keinen extra Platz in der Kapsel und kann theoretisch auf jede mögliche Frachtkapsel oben drauf gesetzt werden, solange die Adapter stimmen. Ein Großer Nachteil des Towers ist allerdings, dass wenn man ihn abstößt ist er unwiederbringlich weg.
Der Vorteil des integrierten Pusher Systems, wenn man es nicht als LES verwendet ist, dass es auch als Bremsraketen bei der Landung oder als Steuerdüsen im Weltraum verwendet werden kann. Es bleibt außerdem den ganzen Flug über verfügbar, für den Fall dass doch irgendwann noch etwas schief geht.
Zusammenfassend kann man sagen, dass beide Systeme ihre Vor- und Nachteile haben. Was allerdings bei beiden System hinzu kommt, ist dass sie beide auf einer Technologie basieren, für welche sie selbst die Notlösung bei Fehlern bieten, nämlich den Raketen an sich. Ein LES basiert auf der Fortbewegung durch Rakete und hat ähnliche Anfälligkeiten und Nachteile. Tatsächlich gab es zum glück aber auch nur sehr wenige Fälle bei denen ein LES wirklich eingesetzt werden musste.
Während man sich beim Flug in den Orbit vorwiegend darüber Gedanken machen muss, wie man die benötigte Geschwindigkeit aufbauen kann um in einem Stabilen Orbit zu bleiben, muss man sich bei der Landung darum kümmern genau diese Geschwindigkeit sicher wieder abzubauen. Neben der aktiven Möglichkeit Schub entgegengesetzt der aktuellen Flugbahn zugeben und somit die Geschwindigkeit zu verringern gibt es noch die passive Möglichkeit lediglich durch Reibung die Geschwindigkeit zu verringern. Dies hat den Vorteil, dass kein zusätzlicher Treibstoff mehr gebraucht wird, welcher in erster Linie auch mit in den Orbit gebracht werden müsste. Der offensichtliche Nachteil ist, dass extreme Geschwindigkeiten nur durch Luftreibung abgebaut werden und somit extreme Hitze entsteht. Auch wenn diese Hitze dafür sorgt, dass kleine Meteoriten in der Atmosphäre verglühen und somit keinen Schaden auf der Oberfläche anrichten können, soll eben dieses Verglühen bei den Raumkapseln welche aus dem Orbit zurückkehren verhindert werden.
Damit die Kapsel nun die extreme Hitze aushalten kann muss sie auf die eine oder andere Weise widerstandsfähig gemacht werden. Dies kann entweder durch aktives, passives oder sogenanntes ablatives cooling oder aber durch heat absorption geschehen.
Unter aktiver und passiver Kühlung sind relative klassische Kühlungssysteme. Dabei wird die Hitze, welche von der Struktur aufgenommen wird wieder nach und nach an die Umgebung abgegeben. Dies kann entweder passiv passieren, wenn der Wärmeaustausch einfach durch die Struktur selbst stattfindet und nicht weiter eingegriffen wird. Oder aktiv, wenn zum Beispiel Kühlflüssigkeit durch die Struktur gepumpt wird und somit die Wärme schneller abgeleitet werden kann, damit sie sich nicht an einem Punkt aufstaut und dort die Struktur eventuell beschädigt. Und obwohl diese Kühlungsverfahren so gut wie überall problemlos funktionieren, sind sie für die Raumfahrt und vor allem für den Wiedereintritt in die Atmosphäre nicht effektiv genug. Die Hitze vor der Kapsel staut entwickelt sich so schnell und wird so heiß (bis zu 2000°C), dass selbst stahl sofort zu schmelzen beginnt, noch ehe ein passives oder aktives Kühlungsverfahren richtig greifen kann.
Um dies zu umgehen gibt es im Prinzip zwei Möglichkeiten. Erstens die Nutzung eines sehr viel hitzebeständigeren Materials, das die Temperaturen aushalten kann. Und zweitens zu verhindern, dass die extremheiße Luft die Kapsel überhaupt berührt und somit seine Hitzeenergie gar nicht übertragen kann.
Für die erste Möglichkeit, der sogenannten heat absorbtion, wurden vor allem für das Amerikanische Space Shuttle Programm spezielle Materialien entwickelt. Sie nehmen die Hitze beständig immer und immer weiter auf und können viel mehr Hitze aushalten, als herkömmliche Materialien. Das Problem mit diesem Materialien ist allerdings, dass sie meistens strukturell nicht so stabil wie etwa Stahl sind. Bei den hohen Geschwindigkeiten, mit denen die Kapsel oder das Space Shuttle unterwegs ist, können bereits Regentropfen ausreichen um das Hitzeschild zu beschädigen und somit nutzlos zu machen. Denn es langt, wenn nur an einer einzigen kleinen Stelle die Hitze das Schild durchdringt um die dahinterliegende Struktur zu zerstören.
Bei der zweite Möglichkeit, dem sogenannte ablative cooling, wird im gegensatz zu den anderen Techniken darauf gesetzt, dass das Hitzeschild im verlaufe der Landung zerstört wird. Ziel dieses verfahrens ist es, die Luft die sich vor der Kapsel erhitzt von der eigentlichen Struktur fern zu halten. Hierfür wird das Material des ablativen Hitzeschildes kontrolliert abgebrannt um eine Gasschicht zwischen der Heißen Luft und der Kapsel zu bilden. Diese Gasschicht, welche sich aus den verbrennungsgasen der Hitzeschildes zusammensetzt ist zwar auch sehr heiß, allerdings nicht so extrem Heiß, wie die Luft, weshalb viel besser mit dieser Hitze umgegangen werden kann. Die große Herausforderung des ablativen Hitzeschildes ist es natürlich, überall gleichmäßig ein entsprechenden Gaspuffer aufzubauen, denn sonst wird es wieder nutzlos.
Natürlich lassen sich alle oben genannten verfahren gemeinsam verwenden. Dies erhöht zwar die Sicherheit, weil mehrere Schichten die potentielle Hitze abfangen können, aber macht die Kapsel auch wieder schwerer, was mit deutlich höheren Kosten verbunden ist.
Kommt man am Ende heil durch die Atmosphäre, bleibt für das letzte Stückchen meist der altbewährte Fallschirm um sanft auf wieder auf der Erde anzukommen.
In recent years, since the Internet has become available to almost anyone, application and runtime security is important more than ever. Be it an (unknown) application you download and run from the Internet or some server application you expose to the Internet, it’s almost certainly a bad idea to run apps without any security restrictions applied: Continue reading →
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.
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?
Written by Tim Tenckhoff – tt031 | Computer Science and Media
The mysterious dark part of the internet – hidden in depths of the world wide web, is well known as a lawless space for shady online drug deals or other criminal activities. But in times of continuous tracking on the Internet, personalized advertising or digital censorship by governments, the (almost) invisible part of the web promises to bring back lost anonymity and privacy as well. This blogpost aims to shed light into the dark corners of the deep web and primarily deals with the explanation of how TOR works.
So, what exactly is the deep web? To explain this, it makes sense to cast a glance at the overall picture. The internet as most people know it, forms only a minimal proportion of the overall 7.9 Zettabyte (1 ZB = 10007 bytes = 1021 bytes = 1000000000000000000000 bytes = 1 trillion Gigabytes?) of data available online (Hidden Internet 2018). This huge amount of data can be separated into three parts:
As seen in the picture above, we are accessing only 4% available on search engines like Google or Bing. The remaining 96% (90% + 4%) are protected by passwords, hidden behind paywalls or can be accessed via special tools (Hidden Internet 2018). But what separates the hidden parts into Deep Web and Dark Web by definition?
The Deep Web is fundamentally referred to data which are not indexed by any standard search engines as e.g. Google or Yahoo. This includes all web pages that search engines cannot find, such as user databases, registration-required web forums, webmail pages, and pages behind paywalls. Thus, the Deep Web can, of course, contain content that is totally legal (e.g. governmental records).
The Dark Web is a small unit of the Deep Web – which refers to web pages that cannot be found by common search engines. The collection of websites that belongs to this dark web only exists on an encrypted network that cannot be reached by regular browsers (such as Chrome, Firefox, Internet Explorer, etc.). In conclusion, this area is the well-suited scene of cybercrime. Accessing these Dark Websites requires the usage of the Tor Browser.
…hidden crime bazaars that can only be accessed through special software that obscures one’s true location online.
The pre-alpha version of the Tor Browser was released on September 2002 (Onion Pre Alpha 2002
and the Tor Project, the company maintaining Tor, was started in 2006. The name Tor consists of three subterms and is the abbreviation of The onion router.
The underlying Onion Routing Protocol was initially developed by the US Navy in the mid-1990s at the U.S Naval Research Laboratory (Anonymous Connections 1990). The protocol basically describes a technique for anonymous communication over a public network: By encapsulating each message carried in several layers of encryption and redirecting Internet traffic through a free, worldwide overlay network. It is called onion routing because of the layers in this network and the layers of an onion. Developed as free and open-source software for enabling anonymous communication, the Tor-Browser still follows the intended use today: protecting personal privacy and communication by protecting internet activities from being monitored.
With the Tor Browser, barely anyone can get access to The Onion Router (Tor) network by downloading and running the software. The browser does not need to be installed in the system and can be unpacked and transported as portable software via USB stick (Tor Browser 2019).
As soon as this is done, the browser is able to connect to the Tor network. This is a network of many servers, the Tor nodes. While surfing, the traffic is encrypted by each of these Tor nodes. Only at the last server in the chain of nodes, the so-called exit node, the data stream is decrypted again and normally routed via the Internet to the target server, which is located in the address bar of the Tor browser. In concrete terms, the Tor browser first downloads a list of all available Tor servers for the connection over the Tor network and then defines a random route from server to server for data traffic, which is called Onion Routing as said before. These routes consist of a total of three Tor nodes, with the last server being the Tor exit node (Tor Browser 2019).
For the reason that traffic to the Onion service runs across multiple servers from the Tor Project, the traces that users usually leave while surfing with a normal Internet browser or exchanging data such as email and messenger messages become blurred. Even though the payload of normal Internet traffic is encrypted, e.g. via https, the header containing routing source, destination, size, timing etc. can simply be spied by attackers or Internet providers. Onion routing in contrast also obscures the IP address of Tor users and keeps their computer location anonymous. To continuously disguise the data route, a new route through the Tor network is chosen every ten (Tor Browser 2019) minutes. The exact functionality of the underlying encryption will be described later in section Onion Routing – How Does Tor Work?.
3. The Tor-Network
For those concerned about the privacy of their digital communications in times of large-scale surveillance, the Tor network provides the optimal obfuscation. The following section explains which content can be found on websites hidden in the dark web, how the multi-layered encryption works in detail, and what kind of anonymity it actually offers.
Most of the content in relation to the darknet involves nefarious or illegal activity. With the provided possibility of anonymity, there are many criminals trying to take advantage of it. This results in a large volume of darknet sites revolving around drugs, darknet markets (sites for the purchase and sale of services and goods), and fraud. Some examples found within minutes using the Tor browser are listed in the following:
Drug or other illegal substance dealers: Darknet markets (black markets) allow the anonymous purchase and sale of medicines and other illegal or controlled substances such as pharmaceuticals. Almost everything can be found here, quite simply in exchange for bitcoins.
Hackers: Individuals or groups, looking for ways to bypass and exploit security measures for their personal benefit or out of anger for a company or action (Krebs On Security 2016), communicate and collaborate with other hackers in forums, share security attacks (use a bug or vulnerability to gain access to software, hardware, data, etc.) and brag about attacks. Some hackers offer their individual service in exchange for bitcoins.
Terrorist organizations use the network for anonymous Internet access, recruitment, information exchange and organisation (What is the darknet?).
Counterfeiters: Offer document forgeries and currency imitations via the darknet.
Merchants of stolen information offer e.g. credit card numbers and other personally identifiable information can be accessed and ordered for theft and fraud activities.
Weapon dealers: Some dark markets allow the anonymous, illegal purchase and sale of weapons.
Gamblers play or connect in the darknet to bypass their local gambling laws.
Murderers/assassins: Despite of existing discussions about whether these services are real or legitimate, created by the law enforcement or just fictitious websites, some dark websites exist, that offer murder for rent.
Providers of illegal explicit material e.g. child pornography: We will not go into detail here.
But the same anonymity also offers a bright side: freedom of expression. It offers the availability to speak freely without fear about persecution in countries where this is no fundamental right. According to the Tor project, hidden services allowed regime dissidents in Lebanon, Mauritania and the Arab Spring to host blogs in countries where the exchange of those ideas would be punished (Meet Darknet 2013). Some other use-cases are:
To use it as a censorship circumvention tool, to reach otherwise blocked content (in countries without free access to information)
Socially sensitive communication: Chat rooms and web forums where rape and abuse survivors or people with illnesses can communicate freely, without being afraid of being judged.
A further example of that is the New Yorker’s Strongbox, which allows whistleblowers to upload documents and offers a way to communicate anonymously with the magazine (Meet Darknet 2013).
3.2 Accessing the Network
The hidden sites of the dark web can be accessed via special onion-domains. These addresses are not part of the normal DNS, but can be interpreted by the Tor browser if they are sent into the network through a proxy (Interaction with Tor 2018). In order to create an onion-domain, a Tor daemon first creates an RSA key pair, calculates the SHA-1 hash over the generated public RSA key, shortens it to 80 bits, and encodes the result into a 16-digit base32 string (e.g. expyuzz4waqyqbqhcn) (Interaction with Tor 2018). For the reason that onion-domains directly derive from their public key, they are self-certifying. That implements, that if a user knows a domain, he automatically knows the corresponding public key. Unfortunately, onion-domains are therefore difficult to read, write, or to remember. In February 2018, the Tor Project introduced the next generation of onion-domains, which can now be 56 characters long, use a base32 encoding of the public key, and includes a checksum and version number (Interaction with Tor 2018). The new onion services also use elliptic curve cryptography so that the entire public key can now be embedded in the domain, while it could only be the hash in previous versions. These changes led to enhanced security of onion-services, but long and unreadable domain names interfered the usability again (Interaction with Tor 2018). Therefore, it is a common procedure, to repeatedly generate RSA keys until the domain randomly contains the desired string (e.g. facebook). These vanity onion domains look like this for e.g. Facebook (facebookcorewwwi.onion) or the New York Times (nytimes3xbfgragh.onion) (Interaction with Tor 2018). In contrast to the rest of the Worldwide Web, where navigation is primarily done via search engines, the darknet often contains pages with lists of these domains for further navigation. The darknet deliberately tries to hide from the eyes of the searchable web (Meet Darknet 2013)
3.3 Onion Routing – How Does Tor Work?
So how exactly does the anonymizing encryption technology behind Onion Routing work?
As said before, the Tor browser chooses an encrypted path through the network and builds a circuit in which each onion router only knows (is able to decrypt) its predecessor and the successor, but no other nodes in the circuit. Tor thereby uses the Diffie-Hellman algorithm to generate keys between the user and different onion routers in the network (How does Tor work 2018). The algortihm is one possible application of Public Key Cryptography that makes use of two large prime numbers which are mathematically linked:
A public-key — public and visible to others
A private-key — private and kept secret
The public key can be used to encrypt messages and the private key is in return used to decrypt the encrypted content. This implicates, that anyone is able to encrypt content for a specific recipient, but this recipient alone can decrypt it again (How does Tor work 2018).
Tor normally uses 3 nodes by default, so 3 layers of encryption are required to encrypt a message (How does Tor work 2018). It is important to say, that every single Tor packet (called cell) is exactly 512kb large. This is done for the reason, that attackers cannot guess which cells are larger cells e.g images/media (How does Tor work 2018). On every step, the transferred message/package reaches, one layer of encryption is decrypted, revealing the position of the next successor in the circuit. This makes it possible, that nodes in the circuit do not know where the previous message originated or where its final destination is (How does Tor work 2018). A simplified visualization of this procedure can be seen in the picture below.
But how does the network allow different users to connect without knowing each other’s network identity? The answer are so-called “rendezvous points”, formerly known as hidden services. (Onion Service Protocol 2019). The following steps are mainly extracted and summarized from the official documentation of Tor about the Onion Service Protocol 2019 and describe the technical details of how this is made possible:Step 1: Before a client is able to contact an onion service in the network, it needs to broadcast its existence. Therefore, the service randomly selects relays in the network and requests them to act as introduction points by sending its public key. The picture below shows these circuit connections in the first step as green lines. It is important to mention, that these lines mark Tor circuits and not direct connections. The full three-step circuit makes it hard to associate an introduction point with the IP address of an onion server: Even though the introduction point is aware of the onion servers identity (public key) it does never know the onion server’s location (IP address)(Onion Service Protocol 2019).
Step 2: Step two: The service creates a so-called onion service descriptor that contains its public key and a summary of each introductory point (Onion Service Protocol 2019). This descriptor is signed with the private key of the service and then uploaded to a distributed hash database table in the network. If a client requests an onion domain as described in section Accessing the Network the respective descriptor is found. If e.g. “abc.onion” is requested, “abc” is a 16 or 32 character string derived by the service’s public key as seen in the picture below.
When a client contacts an onion-service it needs to initiate the connection by downloading the descriptor from the distributed hash table as described before. If that certain descriptor exists for the address abc.onion, the client receives the set of introduction points and the respective public key. This action can be seen in the picture below. At the same time, the client establishes a connection circuit to another randomly selected node in the network and asks it to act as a rendezvous point by submitting a one time-secret key (Onion Service Protocol 2019).
Now the client creates a so-called introduce message (encrypted with the public key of the onion service), containing the address of the rendezvous point and the one-time secret key. This message is sent to one of the introduction points, requesting the onion service as its final target. For the reason that the communication is again realized by a gate circuit, it is not possible to uncover the clients IP address and thus its identity.
At this point, the onion service decodes the introduce message including the address of the rendezvous point and the one-time secret key. The service is then able to establish a circuit connection to the now revealed rendezvous point and communicates the one-time secret in a rendezvous message to the node. Thereby, the service remains with the same set of entry guards for the creation of new circuits (Onion Service Protocol 2019).
By application of this technique, an attacker is not able to create his own relay to force the onion service to create an optional number of circuits, so that the corrupt relay might be randomly selected as the entry node.
This attack scenario which is able to uncover the anonymity in the Deep Web networks was described by Øverlier and Syverson in their paper (Locating Hidden Servers 2006).
As seen in the last picture below, the rendezvous point informs the client about the successfully established connection.
Afterwards, both the client and onion service are able to use their circuits to the rendezvous point to communicate. The (end-to-end encrypted) messages are forwarded through the rendezvous point from client to the service or vice versa (Onion Service Protocol 2019).
The initial introduction circuit is never used for the actual communication for one important reason mainly: A relay should not be attributable to a particular onion service. The rendezvous point is therefore never aware of the identity of any onion service (Onion Service Protocol 2019).
Altogether, the complete connection between service and onion service and client consists of six nodes: three selected by the client, whereas the third is the rendezvous point and the other three are selected by the service.
4. Conclusion – Weaknesses
Different from what many people believe (How does Tor work 2018) Tor is no completely decentralized peer-to-peer system. If it was, it wouldn’t be very useful, as the system requires a number of directory servers that continuously manage and maintain the state of the network.
Furthermore, Tor is not secured against end-to-end attacks. While it does provide protection against traffic analysis, it cannot and does not attempt to protect against monitoring of traffic at the boundaries of the Tor network (the traffic entering and exiting the network), which is a problem that cyber security experts were unable to solve yet (How does Tor work 2018). Researchers from the University of Michigan even developed a network scanner allowing identification of 86% of worldwide live Tor “bridges” with a single scan (Zmap Scan 2013).
Another disadvantage of Tor is its speed – because the data packages are randomly sent through a number of nodes, and each of them could be anywhere in the world, the usage of Tor is very slow.
Despite its weaknesses, the Tor browser is an effective, powerful tool for the protection of the user’s privacy online, but it is good to keep in mind that a Virtual Private Network (VPN) can also provide security and anonymity, without the significant speed decrease of the Tor browser (Tor or VPN 2019) . If total obfuscation and anonymity regardless of the performance play a decisive role, a combination of both is recommended.
Interaction with Tor , Philipp Winter, Anne Edmundson, Laura M. Roberts, Agnieszka Dutkowska-Zuk, Marshini Chetty, Nick Feamster, How Do Tor Users Interact With Onion Services?[Online] Available at: https://arxiv.org/pdf/1806.11278.pdf [Accessed 16. August 2019].
In the past couple of years research in the field of machine learning (ML) has made huge progress which resulted in applications like automated translation, practical speech recognition for smart assistants, useful robots, self-driving cars and lots of others. But so far we only have reached the point where ML works, but may easily be broken. Therefore, this blog post concentrates on the weaknesses ML faces these days. After an overview and categorization of different flaws, we will dig a little deeper into adversarial attacks, which are the most dangerous ones.
Nowadays, the usage of mobile devices has become a part of our everyday life. A lot of sensitive and personal data is stored on these devices, which makes them more attractive targets for attackers. Also, many companies offer the possibility to work remotely, which results in storing confidential business information on private phones and therefore increases the organizations’ vulnerability. The following content shows what kind of attacks the mobile platform is facing and how secure we really are.
Today’s software is more vulnerable to cyber attacks than ever before. The number of recorded vulnerabilities has almost constantly increased since the early 90s. The strong competition on the software market along with many innovative technologies getting released every year forces modern software companies to spend more resources on development and less resources on software quality and testing. In 2017 alone, 14.500 new vulnerabilities were recorded by the CVE (Common Vulnerability and Exposures) database, compared to the 6.000 from the previous year. This will continue in the years to come.