Modern approach to information security
I love information security. On the one hand, a business often requires rolling out half-baked prototypes, deployed once an hour. On the other hand, it is the harsh and unapproachable stronghold of information security officers. Everything depends on them. And even developments in the field of IoT, where S is security, become even more reliable under their supervision.
The key issue in estimating the
And a list. Everyone loves lists. I will give my small set of necessary software, which greatly brightens up my everyday life.
If something is boring, you need to automate
The classic testing pyramid. Somewhere at the bottom there are numerous unit tests that cover all sorts of little things, like making sure the application doesn't crash if the user enters their Hindi password. Or sent something else strange. And then there were precedents with "لُلُصّبُلُلصّبُررً ॣ ॣ h ॣ ॣ 冗" on the iPhone, if you remember. This type of testing is great for its automation, but only covers narrow cases that often fail to give a complete picture and confidence that the application will not flow in an unexpected place.
At the very top, it's already completely manual testing. In addition to checking standard cases, it can provide for "free creativity", when a specialist is given the task of breaking something in any exotic way to his liking. As always, this kind of creative approach leads to the fact that this type of test is also the most expensive. Not only in terms of money, but also the notorious time-to-market, when you need to roll out new features just-right-yesterday-at-a-meeting-already-promised.
A traditional problem faced by many companies is long and sad coordination with information security on each item. Not because they are so angry and unfriendly. It's just that their task is to minimize risks. So they minimize as much as they can, simultaneously stopping half of the processes in the bottleneck of their checks. Actually, in pre-Jail times, when you could slowly polish your code, this worked. And now 47 half-baked prototypes from competitors with monkey coders will already be released to your polished solution of the first version. And that's all. You have already lost the market, all users are stuck in another Tick-Tock.
Pipeline for everything
In fact, most often the problem is poor integration of information security processes into pipelines already familiar to developers. For some reason, each push is accompanied by many checks from the same flake8 and mypy, it is assembled into a package itself, uploaded to the container of the GitLab runner and happily flies away tested in Artifactory. Or fails a stage and returns for revision.
And only information security is often under a magnifying glass with his hands every release, flipping through the code and poking a stick into the open ports of the application. It seems to me that one of the best solutions is to move the main part of security checks into an automatic process, and limit manual testing in time. IB retains the right of veto if they find a critical vulnerability, but by default the application flies into production if there were no objections from their side. It sounds scary at first glance, but such a process structure motivates to automate all routine procedures as much as possible and spend time only on really complicated things.
These abbreviations like DevSecOps and other TriCeraTops scare me a little, but this is exactly what most often needs to be organized to reduce time costs. Let's take a look at a python example. It's worth starting with linters. I think that almost everyone has screwed on some variants of basic linters like flake8 and mypy. I would still recommend the extended version of flake8 - wemake-python-styleguide.
It is installed and started traditionally:
pip install wemake-python-styleguide
flake8 your_module.pyThe main problem with this linter is that it can make you want to break the monitor with the keyboard at first. Especially in old legacy projects, it's easier to burn than fix. Nevertheless, if you exclude unnecessary checks, you will get rather strict control over the quality of the underlying code.
After we have checked the code itself for crooked constructions, poor readability and high cyclomatic complexity, we should run the static security linter. Yes, in loosely typed languages such linters are not so good, but they allow you to identify typical problems like password = 'qwerty123' in the code. You can use the same bandit here .
This all works great, but the problem with free solutions is most often in less up-to-date vulnerability databases. Most often it makes sense to add something else likesafety .
Source
Similar checkout options usually integrate perfectly with the same corporate GitLab.
That being said, there is usually a nice informative output to the console:
safety check --full-report
Ideally, after all the manipulations, you should have a complete pipeline, where you step by step check all the security requirements for your application.
Source
Typical checks:
git secret check - check the absence of open secrets in the
SCA code - check that external dependencies and libraries are free of vulnerabilities. It is important if you are freezing the old version of the
SAST library - static code analysis for vulnerabilities.
Container audit - audit of the container image that will be used for deployment. They are also often full of holes. Especially if you are using exotic sandwiches from many variegated layers.
DAST - application deployment, registration, login as a legitimate user and carrying out typical attacks on the front-end
What remains for information security
Now that we have unloaded the
There will be the same ageless arsenal of tools for analysis, network testing and password guessing. Wireshark, hashcat, Hydra and other utilities have never been retired.
But even among familiar tools, something new and sometimes quite useful appears. I will suggest paying attention to some of them.
Nikto2
github.com/sullo/nikto
Nikto is an open source web server scanner. He's not quiet at all. Seriously, if you launched it from your workplace and for 15 minutes you still do not lie face down on the floor surrounded by security personnel, then you have problems with intrusion detection.
The software performs complex tests on web servers for many elements, including more than 6700 potentially dangerous files / programs. It also checks server configuration items such as HTTP server settings and tries to identify installed web servers and software. Scan items and plugins are updated frequently and may update automatically.
Fuzzdb
It is also a very cool tool for automated attacks against web applications using typical patterns and vulnerabilities. He will happily bombard your application with a bunch of standard attacks and at the same time check if you forgot to cover access to the admin panel and log files with reduced rights. Allows you to relieve a lot of headaches and routine checks.
Nmap + Vulners
Vulners is an aggregator of all kinds of CVEs, vendor security bulletins, exploits in Metasploit, and simply the result of manually catching vulnerabilities in thematic forums. Basically, they provide an API for querying their database. I was simply captivated by their plugin for the well-known nmap, which just immediately gives a fan of ready-made attack vectors for a web service. I highly recommend taking a closer look.
Something like output
Death to humans - glory to robots!
But seriously, try to minimize the routine and pass it on to the one who should really do it - soulless scripts and pipelines. And let people be engaged in creativity. This is more correct.
