A few thoughts about cybersecurity from Young Dev’s View

This post is a little bit about cybersecurity, however I am not a specialist in it. It is just my point of view on securing every web application or other kind of software I create. Please, do not refer to this post as to any kind of source of substantive knowledge. For such purposes, there are better sources i.e. Gynvael’s blog or webinars or books from Sekurak, or seminars on TEDx etc.

As of the fact, I am mainly a web developer, I would concentrate on web application security in this post.

But for starters, let’s talk about three concepts known to security:

  • “security by obscurity” pattern,
  • “security by design” pattern,
  • open security philosophy.

Those schemes are pretty much implemented in every security mechanism: from mechanical ones through electronic to IT security mechanisms.

(Cyber)Security by obscurity

Historical background

There are no sources which state when experts have created the term. The only information is that in 1851 the pattern has been denied as a good practice when used alone. As of the public presentation of Alfred Charles Hobbs, in which he showed off locks flaws, then some people had concerns if it wouldn’t make those mechanisms more vulnerable to rogues. After that he stated as follows: “Rogues are very keen in their profession, and know already much more than we can teach them”. It just means that hiding how the mechanism work, won’t prevent rogues so the possible attackers from doing it. What’s more it won’t even make it more difficult really to break through such mechanism.

So what is important in cybersecurity?

Having all that said, we can define simple observation that security is not about creating mechanism which is 100% durable and safe. I would rather say it is much more about how to create mechanisms which will prevent rogues from attacking.

Despite what I stated earlier, security engineers still use this pattern. And the real thing is that it is good to use it, but as a kind of helper pattern and not the only pattern.

For an example, we would rather use open source projects to secure out web system than something custom made, however we would better not tell anyone which project we have used. Why? It is because people has improved such software for years and have tested it through all these years, what makes it much more reliable than custom-made solution. Such solution would contain a lot of flaws, not because we are not good enough to create such design, but because when we create some commercial software, our most important index is Time To Market. Thus, I mean that when you try to implement security algorithms, you just waste time on doing something what has been already done. And what about the second part?

In my opinion it is just kind of hiding a real implementation of the same algorithm. It makes attack much more complicated because without such details, there are more than one possible scenarios which attackers have to take into account while attacking.

Let’s finish up with cybersecurity myths

To sum up, what I have used above is security by obscurity but mixed up with security by design. The first one, I used to create more than one scenario for the attackers while still using some open source software. And engineers responsible for such software always try to make it “secure by design”, more about it later in this post.

An example of well known myths, related to this pattern:

  • don’t expose servers to WAN;
  • try not to expose software information to public;
  • don’t store any data on machine exposed to WAN;
  • all the servers, even those hidden behind NAT must use TLS or any crypto suit;
  • and much more…

All of those practices are implementation of security by obscurity patterns. And what is more interesting, not really one of them definitely nor practically secures our web system when used just on their own. I won’t describe all those practices here, but might I write another post about it.

Security by design

I have already said a few words about this pattern. This one is considered to be one of best practices. However, it is always good to mix it up a little bit with other patterns or philosophies.

Core logic of cybersecurity by design

The core logic of this pattern is to create an application or the algorithm in this way, what will make it secure from the very beginning. Thus, it just means to create such mechanisms like for example:

  • authentication and authorization using well known algorithms i.e. token based authorization or role/policy based authentication;
  • data input validation;
  • data encryption on persistence level;
  • application should store temporarily used data as short as possible, such data should be anonymous and useless when used outside the context;
  • network level security such as firewalls, NAT/PAT, ACLs etc
  • and much, much, much more…

Examples of out-of-the-box implementations

All of mechanisms mentioned above have ready to use out-of-the-box implementation available i.e.

  • IdentityFramework and IdentityServer, Symfony Security and Sonata Security – as of authentication and authorization,
  • Firebase – secure data persistence using encryption,
  • Redis – for secure temporary persistence of data, allowing easy separation of stored information from meaningful context,
  • whole software such as Docker or virtualizations platforms to easily isolate ecosystem from host,
  • much more…

Example of a cybersecurity real-life scenario

For an example, let’s say we have a simple website. It has not TLS certificate, but it has contact form. The form has the following fields:

  • name and surname,
  • email,
  • phone,
  • message box for any text user will input.

No field in the form is really validated. And the data is not encrypted while sending to the server. What are possible flaws here then? Data is exposed to the attacker, the only thing is to sniff for it. What’s more, we don’t know if the user will really enter email or phone in the fields. If the back-end is not properly secured, we can easily create SQL Injection attack to retrieve data from related table columns. And what about this field in which user can insert anything. In scenario, that user is an attacker it can also contain such query as above or any other script which inject into back-end code i.e. php code will retrieve environment variables from the server etc.

On the other hand, there is a scenario that the attacker is sniffing data, just listening on server’s port or any client’s port so the attacker will receive all data from the form. If the user had entered some sensitive information in such not validated field, the attacker will receive all of them.

I hope, this example even if simple, shows well what is the problem with a bad design. Because all of the flaws could be removed on the design phase of the website. If an engineer responsible for the website would use proper design practices so website’s design will be “secure by design”, those flaws would not exist.

The term of open security

To go even further from the first mentioned pattern, there is an open security philosophy. It was born some time after creation of open source. By design, we use open source software, which is then well-known to any people on the Earth, to secure our product. Paradoxically, it does not create any kind of vulnerability. Using this philosophy mixed up with previous pattern will probably improve security of our product very well. It is because the thing is not to hide the way the mechanism works, the thing is to design it properly.

Final thoughts on cybersecurity

The security or cybersecurity is not really about creating something what is not breakable. I think it is all about creating something what will discourage attacker from… attacking. So, not even it is about hiding anything or making it top secret, but it is about making it look very difficult to break through – I would rather say that the sense it to create the feeling, the psychological effect on attacker while it is possible to break in, it is not worth breaking through all this.

It is all for this post. Thanks for reading and see you next time folks.


Leave a Comment

Your email address will not be published. Required fields are marked *