Information security in generic

Some very generic thoughts about informational security.

Topic is very complicated, but in scope of subject will be described only generics.

This list is not standard or something.

It’s more like marks on fields…


v 0.02

  • Be suspicious and don’t trust anything on words, especially tools with “Secure” in their name; - REMARK: Of course questions of trust and trustworthy - are more complicated and deserve additional post, but main thing - be curious, ask questions and don’t believe in “perfect security by design”;

  • Create good readable documentation for your information security perimeter, technologies, security vectors, to make possible correctly understand risks ; Always work under describing security vectors and vulnerabilities from your technological stack; Remember that this is forever continuous process and should be started not after security breach as reaction, but as pre-action (be pro-active);

  • Firewall should be enabled with white list policy rules and automated;

  • Fix known vulnerabilities; Keep in mind that in military in some cases destroying sensitive vulnerable object by tactical missile strike will also make it secure from information security point of view; In civil place - business, managers, developers or operations - can be against changing something that “works” - they are not your enemies; They just work in another scope of tasks and don’t see it from your angle;

  • Good understandable and readable documentation with description of zones of responsibilities of all team players with including third side members from information security point of view will help you understand scope of your work and make it better (Simply - who will do this and that); Keep it updated if some new system or team member has appeared;

  • Documentation for application layer with full source code available (with all included libraries and dependencies) - is key to pass internal code audit; It’s not everything that’s required, but no source code - no audit/automated testing possible; Of course, fans of proprietary software will tell that we can just trust IT giant’s, as there are huge reputation risks for them, but look at item number one from this list;

  • Kerckhoffs principle recommends to use open implementation rather than closed or specially obfuscated; Security by obfuscation can’t work good where is: 1- lot’s of time or 2- human factor;

  • Human factor can be minimized by access roles and limited privileges access according to requirements. Use the principle of least privilege;

  • IDS (same as DLP and WAF) have different tasks than regular service monitoring; That’s why it should be under different SLA / hardware / people from very beginning;

  • Isolate items; Level of isolation for every peace should be according to system design requirements which should be defined according to risks model and technical requirements; For example: on level 1 - permissions/ owner isolation (…) and 9 - physical isolation on different hardware / vendor in different data-center);

  • MAC/RBAC better to be enabled with white list policy rules and automated;

  • Perform external, internal, and code/application level security audits on regular basis;

  • Minimize attack vectors; If you can avoid using some software, library, hardware or technology - do it;
  • Minimize attack vectors again; If you have software, library, hardware or technology that you don’t use or need now, but it was needed earlier - remove it from production;

  • Passwords/keys keep/recovery/renew documentation will explain what is password manager, what to do when you lost your password/laptop, accidentally commit in public GIT your/corporate private keys - how to change them quickly and how to use them; Here is good article with some recommendations and OWASP cheat sheet;

  • Regular backups should be automated and monitored;
  • Regular backups should be tested and configured according to your SLA with proper RPO and RTO;

  • Offline encrypted backups can make possible perform extra changes audit even is they can be useless from business point of view in long term;

  • Subordinatively and financial - Information security department is not a part of developers, operations or DevOps teams or any others - if you wan’t them to do their job good;

  • Use communication encryption for external systems according to your information security model (VPN’s and transport layer encryption should be checked to be strong enough on regular basis);
  • Use storage encryption according to your information security model;

  • White list is better security strategy than black list, but of course require more resources; For any new software, library, technology default level access policy should be “denied” (file level access, networking, system calls, etc.);


  • Information security will not came to you from called as “secure” magic boxes like: antivirus software, firewalls or any others even if they are very good;
  • I.S. can be represented as exponentially growing complicity multiplied to all weaknesses of all your systems over time;
  • One exploitable vulnerability on production live system can be enough to ruin everything and destroy your business or even life;
  • Main role of I.S. department / specialists - to be in charge of process controlling, identifying risks and minimizing possible impact;
  • From other side - there are nothing perfect in this world and no 100% guarantee even if everything was build correctly that’s security related incidents will not appears. You can be only definitely sure - the probability of huge issues decreased and possible impact was minimized;
comments powered by Disqus