Service support in production, monitoring and fixing errors
After the release, it is important to monitor errors and atypical behavior of metrics for at least a day. The development team should have a resource to quickly fix bugs after the release, I recommend planning tasks in the sprint taking this factor into account. If major bugs were found after the release, then the team should consider steps to prevent similar situations, for example, strengthen code review or testing. Also, any errors should be well read in the logs and metrics. If you learned about a serious error from users, then it is worth introducing new metrics that would clearly signal an emergency situation in the future.
Each company has its own development specifics, but I hope that the steps described above will be valid for a large number of web services. In the comments, share your vision of the correct rollout of the service in production and describe the steps that are used in your companies or projects.
What clients want: full compliance, cybersecurity monitoring without response and less GosSOPKa
Rostelecom-Solar Blog
Information Security
*
All customers are different. Some are tech-savvy and know exactly what they need. Others just want to work without failures and incidents, although they do not understand how to implement it. And someone does not understand information security, but is sure that he knows exactly how to build a process. When it comes to such complex tasks as creating or rebuilding a Security Operations Center (SOC), the difference in approaches to information security becomes apparent. In this series of posts, we decided to share a selection of the most popular requests that companies come to us as a service provider. We have already written about customers who are really good at IT and understand exactly what they want from SOC. And about those who know firsthand what SOC is, but are not so immersed in the question, which ultimately leads to a kind of task setting. In this post, we will talk about companies that see the main risks not in cyber threats, but in inspections and fines from the regulator, missed deadlines, so they just want to hide behind a fig leaf.
A lot of requests from such customers are related to the topic of compliance:
“I want to receive notifications from you earlier than from the NKTsKI.”
“Just organize interaction with the State SOPKA, you have a license.”
“Install a piece of iron so that everything works, like a sensor from the FSB, but for us.”
“Take responsibility for all functions of the GosSOPKA center.”
“Ensure compliance with the requirements of the Central Bank / FSTEC / FSB (underline as necessary)”.
In general, they all boil down to three main tasks:
Identification of threats, incidents, vulnerabilities before the regulator.
Formal closure of requirements during verification.
Transferring areas of responsibility to the service provider.
Let’s deal with each separately.
Identification of threats, incidents, vulnerabilities before the regulator
What’s wrong with this request? It seems that everything is logical: the desire to receive important information as quickly as possible. But usually in this case, the client does not need full-fledged monitoring, incident response, the process of identifying, prioritizing and eliminating vulnerabilities in the infrastructure. He wants point alerts on indicators completely similar to SOPKA sensors, as well as a number of measures aimed at cleaning the perimeter of critical vulnerabilities on the eve of the regulator’s check. Real security in this option is of little concern.
But usually behind such a request is a lack of readiness to establish regular operational work with incidents and vulnerabilities on their side and build functional information security processes. It is important to note here that the SOPKA sensor works on the closed base of the NCCCI, aggregated and prioritized by various sources, but this is not the only way to fix the compromise of the company’s IT infrastructure by the NCCCI. The service provider works much wider, sees more, digs deeper, but without feedback from the customer, he does not understand the context and cannot independently decide (in 99% of cases) whether the activity that he fixes is an incident or not. As a result, the number of notifications from the service provider is dozens per day (and not once a month, as the customer expects), and they are not getting smaller. At this point, the customer’s specialists need to choose: either start working in tandem with the service provider, or accumulate alerts. In the second case, a “letter of happiness” from the regulator will definitely come and you will need to write explanatory letters. Fortunately, in recent years, against the backdrop of an increase in cyber incidents, many companies have begun to evaluate the role of a service provider in a different way, so formal threat detection is becoming less and less common.
Formal closure of requirements during verification
The regulatory burden is perceived by some companies as a formal measure and, in their opinion, has nothing to do with real cybersecurity. But actually it is not. Registration of information security events is a useful requirement, especially if, after registration, the fact of an incident is confirmed, localized, mitigated and restored – that is, a full response cycle. In the case of a formal approach, the list of notifications from a service provider or your own SIEM / IRP looks like an archive of the Lenin Library, which is simply presented to the regulator during verification.
But the missed incident still remains in the area of responsibility of the company that owns the infrastructure: CII, PD, GIS, and so on. And this smoothly brings us to the third type of requests.
Transfer of responsibilities to the service provider
The IS monitoring service provider is not responsible to the regulator for an incident that occurred at the customer’s site (its owner is responsible for what happens on the infrastructure). Of course, if the provider himself caused the incident is another matter (but I hope such cases are extremely rare). Therefore, the approach to transferring certain areas of responsibility should be as reasonable and conscious as possible.