October 4, 2012 at 16:56Safety, instructions and integrators
Good day, dear Khabrovites!
Recently I had to deal with one local integrator in terms of work on FZ-152 and, in general, on information protection. I will not describe the expediency for our small office (I would have done it alone, perhaps a little longer, but an order of magnitude cheaper), since by the time I started working in our organization the question of working with this integrator was resolved and I could only observe and reap the results.
About the results and thoughts, “why is it like that”, under habrakat.
Emergency instructions
That was the name of their most interesting document. I will make a reservation right away - I did not work in integrator companies, I did not do instructions for the customer. It was difficult for me to understand the logic of creating this document, from the person who wrote this document there was only a comment: we successfully implemented it in many organizations and no one had problems!
Now we will move on to excerpts from the text with my comments (omit section 1 - general provisions, as there is a description of laws, etc.):
2. General procedure for emergency situations
2.1. In the event of an emergency during operation, an employee who has discovered an emergency, immediately notifies the information protection administrator.
2.2. The information protection administrator conducts a preliminary analysis of the situation and, if it is impossible to correct the situation, notifies the head of the unit.
2.3. Upon the occurrence of an emergency, an act is drawn up, with a description of the situation. If applicable, explanatory materials are attached to the act (screen copies, printout of the event log, etc.).
2.4. If necessary, an internal investigation is carried out on the occurrence of an emergency and clarification of its causes.
The first that raises questions: what exactly are these abnormal situations? How does an ordinary employee, for example, of the marketing department, find out - is this an emergency situation, or is the result of regular actions?
Why burden the instructions for users (according to the same employee of the integrator) with a description of the administrator's actions?
Next comes section 3. Features of actions in the event of the most common emergency situations. It is large and consists of 14 points, it does not make sense to list all of them, since virtually every section there is an abnormal situation and what to do for the system administrator and ZI administrator in this case (I repeat, the instruction was created for users).
As an example:
3.2. Power outage. The information protection administrator, together with the employee (specify) of the department, analyzes for the loss and (or) destruction of data and software, as well as checks the operability of the equipment. If necessary, the software and data are restored from the latest backup with the drawing up of an act.
3.3. Failure in the local area network (LAN). The information protection administrator, together with the employee (specify) of the department, conduct an analysis for the presence of losses and (or) destruction of data and software. If necessary, the software and data are restored from the latest backup with the drawing up of an act.
Copy-paste just steers!
3.7. An information leak has been detected (security hole). If an information leak is detected, the information protection administrator and the unit head are notified. An internal investigation is underway. If an information leak occurred for technical reasons, an analysis of the system’s security is carried out and, if necessary, measures are taken to eliminate vulnerabilities and prevent their occurrence.
A wonderful wording explaining what information leakage is. Moreover, they divided the NSD and information leakage (a hole in the protection of the system) into two separate points:
3.8. Hacking a system (Web server, file server, etc.) or unauthorized access (NSD). When a server hack is detected, the information protection administrator and the unit head are notified. If possible, a temporary disconnection of the server from the network is carried out to check for viruses and Trojan bookmarks. A temporary switch to the backup server is possible. Given that program bookmarks may not be detected by antivirus software, you should especially carefully check the integrity of executable files in accordance with the hash functions of the reference software, as well as analyze the status of script files and server logs. You must change all the passwords that were related to this server. If necessary, the software and data are restored from the reference archive and backups with the preparation of the act. Based on the results of the analysis of the situation, one should check the probability of penetration of unauthorized programs into the IS of LLC Vector, and then carry out similar work to check and restore software and data at other workstations of IS LLC of Vector. An official investigation is being conducted into a server hack.
3.9. Attempted Unauthorized Access (NSD). When an NSD is attempted, a situation analysis is carried out based on information from the NSD attempt logs and previous NSD attempts. According to the results of the analysis, if necessary, measures are taken to prevent tampering, if there is a real threat of tampering. It is also recommended that unscheduled passwords be changed. In the case of software updates that address security vulnerabilities, you should apply such updates.
Another interesting point in this section, which simply and easily describes the laborious work of creating, testing and debugging a business continuity system:
3.13. Disaster. In the event of natural disasters should be guided by the documents (indicate) for the relevant units of LLC “Vector”. Upon the occurrence of an emergency, an act is drawn up, with a description of the situation. If applicable, explanatory materials are attached to the act (screen copies, printout of the event log, etc.).
Again copy-paste, and from the 2nd section. People wrote clearly far from business continuity. I would see how, at the time of the occurrence of a natural disaster, an act is drawn up upon the fact, screen copies, log printouts, etc. are attached.
Well, this section completes the standard paragraph:
3.14. If necessary, an internal investigation is carried out on the occurrence of an emergency and clarification of its causes.
The fourth section of this tome (I repeat, instructions for users) is called: Prevention against emergencies
4.1. At least (indicate the period), an analysis of registered emergency situations should be carried out to develop measures to prevent them.
4.2. In general, in order to prevent emergency situations, strict compliance with the requirements of the regulatory documents of Vektor LLC and the operating instructions for hardware and software is required.
The first paragraph of this section is a kind of problem management in miniature.
The second point is perplexing. This paragraph could replace all previous 3 pages of text with a 12th font. Well, or this is such a hint at the same document, that is, recursion.
Reflections on the topic
The integrator who created this document for us, rather large in our region, has been working for a long time and is known.
That is, the situation is most likely to be created: a young specialist who has just graduated from a university in the prestigious specialty of Information Security gets to work for this integrator. He writes a similar document for the customer. The customer has not dealt with information security documents before (we still have a soviet look at this industry) and accepts this document, introduces his employees to it under his signature and somehow fulfills the requirements.
I repeat, I have never worked for integrators. I was engaged in information security for those organizations in which I worked, I made instructions for myself and my employees.
Why create such a difficult to digest and ignorant document, overflowing with blind copy-paste?
Really young specialists have not heard about best practice and a variety of foreign safety standards?
During his work in the field of information security, he understood 2 main things:
1. Information security is primarily people, only then technology.
2. Instructions must be executed on the machine, for this they must be written accessible and with as few points as possible (ideally - the user's actions are described in steps with the responsible and their contacts).
Dear integrators! Please monitor the quality of your recommendations and recommended documents. Create them, as for yourself, and not on the "dump"!
PS I hope the staff of the integrator companies will be able to note in the comments.
PPSAll communications with real LLC Vector are random.
UPD: if you merge a topic or karma, unsubscribe, pliz, in comments for what. I will know and improve.
Recently I had to deal with one local integrator in terms of work on FZ-152 and, in general, on information protection. I will not describe the expediency for our small office (I would have done it alone, perhaps a little longer, but an order of magnitude cheaper), since by the time I started working in our organization the question of working with this integrator was resolved and I could only observe and reap the results.
About the results and thoughts, “why is it like that”, under habrakat.
Emergency instructions
That was the name of their most interesting document. I will make a reservation right away - I did not work in integrator companies, I did not do instructions for the customer. It was difficult for me to understand the logic of creating this document, from the person who wrote this document there was only a comment: we successfully implemented it in many organizations and no one had problems!
Now we will move on to excerpts from the text with my comments (omit section 1 - general provisions, as there is a description of laws, etc.):
2. General procedure for emergency situations
2.1. In the event of an emergency during operation, an employee who has discovered an emergency, immediately notifies the information protection administrator.
2.2. The information protection administrator conducts a preliminary analysis of the situation and, if it is impossible to correct the situation, notifies the head of the unit.
2.3. Upon the occurrence of an emergency, an act is drawn up, with a description of the situation. If applicable, explanatory materials are attached to the act (screen copies, printout of the event log, etc.).
2.4. If necessary, an internal investigation is carried out on the occurrence of an emergency and clarification of its causes.
The first that raises questions: what exactly are these abnormal situations? How does an ordinary employee, for example, of the marketing department, find out - is this an emergency situation, or is the result of regular actions?
Why burden the instructions for users (according to the same employee of the integrator) with a description of the administrator's actions?
Next comes section 3. Features of actions in the event of the most common emergency situations. It is large and consists of 14 points, it does not make sense to list all of them, since virtually every section there is an abnormal situation and what to do for the system administrator and ZI administrator in this case (I repeat, the instruction was created for users).
As an example:
3.2. Power outage. The information protection administrator, together with the employee (specify) of the department, analyzes for the loss and (or) destruction of data and software, as well as checks the operability of the equipment. If necessary, the software and data are restored from the latest backup with the drawing up of an act.
3.3. Failure in the local area network (LAN). The information protection administrator, together with the employee (specify) of the department, conduct an analysis for the presence of losses and (or) destruction of data and software. If necessary, the software and data are restored from the latest backup with the drawing up of an act.
Copy-paste just steers!
3.7. An information leak has been detected (security hole). If an information leak is detected, the information protection administrator and the unit head are notified. An internal investigation is underway. If an information leak occurred for technical reasons, an analysis of the system’s security is carried out and, if necessary, measures are taken to eliminate vulnerabilities and prevent their occurrence.
A wonderful wording explaining what information leakage is. Moreover, they divided the NSD and information leakage (a hole in the protection of the system) into two separate points:
3.8. Hacking a system (Web server, file server, etc.) or unauthorized access (NSD). When a server hack is detected, the information protection administrator and the unit head are notified. If possible, a temporary disconnection of the server from the network is carried out to check for viruses and Trojan bookmarks. A temporary switch to the backup server is possible. Given that program bookmarks may not be detected by antivirus software, you should especially carefully check the integrity of executable files in accordance with the hash functions of the reference software, as well as analyze the status of script files and server logs. You must change all the passwords that were related to this server. If necessary, the software and data are restored from the reference archive and backups with the preparation of the act. Based on the results of the analysis of the situation, one should check the probability of penetration of unauthorized programs into the IS of LLC Vector, and then carry out similar work to check and restore software and data at other workstations of IS LLC of Vector. An official investigation is being conducted into a server hack.
3.9. Attempted Unauthorized Access (NSD). When an NSD is attempted, a situation analysis is carried out based on information from the NSD attempt logs and previous NSD attempts. According to the results of the analysis, if necessary, measures are taken to prevent tampering, if there is a real threat of tampering. It is also recommended that unscheduled passwords be changed. In the case of software updates that address security vulnerabilities, you should apply such updates.
Another interesting point in this section, which simply and easily describes the laborious work of creating, testing and debugging a business continuity system:
3.13. Disaster. In the event of natural disasters should be guided by the documents (indicate) for the relevant units of LLC “Vector”. Upon the occurrence of an emergency, an act is drawn up, with a description of the situation. If applicable, explanatory materials are attached to the act (screen copies, printout of the event log, etc.).
Again copy-paste, and from the 2nd section. People wrote clearly far from business continuity. I would see how, at the time of the occurrence of a natural disaster, an act is drawn up upon the fact, screen copies, log printouts, etc. are attached.
Well, this section completes the standard paragraph:
3.14. If necessary, an internal investigation is carried out on the occurrence of an emergency and clarification of its causes.
The fourth section of this tome (I repeat, instructions for users) is called: Prevention against emergencies
4.1. At least (indicate the period), an analysis of registered emergency situations should be carried out to develop measures to prevent them.
4.2. In general, in order to prevent emergency situations, strict compliance with the requirements of the regulatory documents of Vektor LLC and the operating instructions for hardware and software is required.
The first paragraph of this section is a kind of problem management in miniature.
The second point is perplexing. This paragraph could replace all previous 3 pages of text with a 12th font. Well, or this is such a hint at the same document, that is, recursion.
Reflections on the topic
The integrator who created this document for us, rather large in our region, has been working for a long time and is known.
That is, the situation is most likely to be created: a young specialist who has just graduated from a university in the prestigious specialty of Information Security gets to work for this integrator. He writes a similar document for the customer. The customer has not dealt with information security documents before (we still have a soviet look at this industry) and accepts this document, introduces his employees to it under his signature and somehow fulfills the requirements.
I repeat, I have never worked for integrators. I was engaged in information security for those organizations in which I worked, I made instructions for myself and my employees.
Why create such a difficult to digest and ignorant document, overflowing with blind copy-paste?
Really young specialists have not heard about best practice and a variety of foreign safety standards?
During his work in the field of information security, he understood 2 main things:
1. Information security is primarily people, only then technology.
2. Instructions must be executed on the machine, for this they must be written accessible and with as few points as possible (ideally - the user's actions are described in steps with the responsible and their contacts).
Dear integrators! Please monitor the quality of your recommendations and recommended documents. Create them, as for yourself, and not on the "dump"!
PS I hope the staff of the integrator companies will be able to note in the comments.
PPSAll communications with real LLC Vector are random.
UPD: if you merge a topic or karma, unsubscribe, pliz, in comments for what. I will know and improve.