Greetings to all! I work in the Department of Information Security
LANIT , I lead the department of design and implementation. In this article I want to share my experience, as at the start of a career, a completely different company prepared a standard for organizing the protection of personal data in medical institutions. This is a story about how to write 500 pages from scratch in 10 days, mistakes made and difficulties that were not overcome. I hope my experience will help everyone who has been assigned the task of writing a guidance document, standard or law.
A sourceMonth to day X
The year 2009 in the field of personal data security was a year of anticipation. There were persistent rumors that 152- “About personal data”, adopted in 2006, is about to become mandatory for execution. The market and operators took time to prepare for the mandatory execution of the law, and it expired. Nobody knew that the law would take effect only in 2011, and business and government agencies assumed that in the near future they would have to work long and hard to be in time.
One of the first who began to prepare was the department that oversaw a huge reservoir of operators of high-profile personal data — medical institutions that operate on patient health data, and therefore attention to such important information is increased. For the sake of brevity, I will call them health facilities - medical institutions.
')
Since healthcare institutions are underdeveloped by IT, not to mention information security, they decided for all medical institutions to create a standard for the protection of personal data that people who are far from security and IT could use.
Most of the governing documents on the protection of personal data were not available to a wide range of people (the so-called “quad book” with the heading “For official use” acted only by licensees), so the option of creating detailed guidelines was optimal.
In 2009, I was engaged in information security for only three years and was at the level of an experienced junior. I could boast of a couple of projects on personal data (which was a great experience at that time, because it is very difficult to convince the customer to fulfill non-binding requirements) and was in a tough bout with one large research institute. Of course, I got the job of creating a standard.
A sourceWeek to day X
A week before the work began, I discussed the upcoming task with the management and it was planned that another specialist would do it, but in the end I had to fight it. As a young man, I acted on the principle of "dementia and courage," and it was this principle that played a key role in all the work. However, this is typical of all specialists at a certain stage of their career.
How was my bravery manifested in the project? I had to solve such a large-scale task exclusively on my own - it looked like an attack “with checkers on tanks”.
Much later, I participated in five similar projects, leading groups from 2 to 6 people. Now I can say with confidence: the optimal number of people for a similar task is 2 people, not counting the specialists involved, such as technical writers. In total, five people should work in the team (2 analysts, technical writer, consultant and project manager). There is a case in my memory when a team of five people did a similar job for 9 months.
Weak-mindedness consisted in the terms of work indicated by me - 10 days, which instead of workers became calendar. The underestimation of the complexity almost became fatal. This time the courage won, but the path was difficult.
A source1-3 day work
Since I had never done anything like this before, I decided to use the existing methods for creating documents. Remembering the most ambitious document that I wrote by that moment - my diploma, I decided to start from the beginning and finish at the end.
The first document was “
Guidelines for the compilation of the Private Model of Personal Data Security Threats ”. (By the way, all documents
can be found on the Internet ). I worked with threat models the most, and this task was most understandable. This was the first mistake.
Without going into details, I had to describe three successive stages in the protection of personal data:
- survey,
- making a threat model
- creating a set of organizational and regulatory documents.
Of course, I began to describe from the middle, which resulted in big problems for 7-10 days.
The second mistake was the use of a consistent principle of writing documents. This is when the title page is first, then the table of contents, the list of abbreviations, the introductory part, etc. It does not work, at some point you will definitely get up in the “creative dead end”, most often it occurs in section 3-5, when you know where you came from and where you want to come, but it’s not clear how.
It was funny with the abbreviations that were immediately made. In order to have at least some continuity with the current regulatory framework, I copied the abbreviations from the regulator's documents, and there remained the abbreviation “TKUI - technical channels of information leakage”, which is not found anywhere in the text.
Layfkhak: to make the list of abbreviations relevant, at the time of writing, use three simple steps:
- As soon as you need to make an abbreviation, write in the format "(hereinafter -)". For example, a mandatory abbreviation in the text (hereinafter - OST).
- Keep open a separate Excel file, where you put all the abbreviations (possible without decryption).
- When the text is written, you rank the list from A to Z in the Excel and see the quantity, and in the text you search for the entry “(hereinafter -)”. If the numbers match, congratulations - you have a current list of abbreviations.
When working with abbreviations, do not use more than three letters. Everything different from this looks awful and poorly remembered. At least in security, where, as in the army, leads all TBS.
Result: 1 file with a volume of 20 pages and several tablets in Excel.
4-6 work day
After the first days of the quiet regime, I had to plunge into the pool of caffeine and nicotine (now I, of course, have a healthy lifestyle). First, a sensible job was done - the technical task was read. In principle, it was clear before that it was necessary to do, but the details were important.
The key words were “guidelines”, i.e. sequence of actions for people poorly familiar with the subject. It will be either the head physician of the health care facility or the secretary Therefore, I decided that it is necessary to describe all possible options so that the user does not have the right to ambiguity: either red, or green, or warm, or soft.
At that moment I worked on a threat model and immediately made tables for all possible types of information systems (I had 10 of them), wrote threats and did other incomprehensible things, interesting only in the context of personal data protection.
After specifying the names of the threats in the tablet, it became clear that somewhere there should be a general description of the threats themselves, then - that our 10 types of information systems are also good to describe somewhere. So, moving step by step, filled the document.
In the process of work, I came to the principle of “reverse movement”, when at the beginning the result is written, which is the essence and purpose of the document, and then iteratively everything that should lead to it.
In general:
- result;
- method of achieving the result;
- description.
The principle was quite tenacious. With it, you can write reports, starting with the findings, or information security policies, starting with the main activities.
Much later, I supplemented this method with the concept of “enhanced JPEG”, which says that work depending on the time must always be 100% ready, the difference is only in the degree of detail. If someone found the times of slow Internet, then the usual JPG was displayed as it was downloaded (the same consistent method of writing documents) from top to bottom, and the JPEG image downloaded the whole and improved its clarity.
One problem - the use of the concept of "improved JPEG" in the forehead does not work for complex documents (at least for me). With direct application, you create sections in a new document and write what they are about, expanding the description as you work it out. In standards and artful techniques this does not work, which I encountered in the next step.
The fact is that it is impossible to foresee everything in advance. The concept of presentation may change several times in the process, and it can change drastically. Therefore, if you fill a document with something more than headings (for example, give explanations, etc.), then in the end you will come to the conclusion that it is necessary not only to rearrange several sentences in places (the very headings), but to edit, divide and supplement those very explanations. Believe, it is very dreary.
Since the guidelines that describe all possible outcomes of the same type, they must match the structure and logic of the description. It would be strange to look if the structure of the system is in one type, but not in the other. And in general, if a user has two types of information systems, he has less opportunity to get confused in descriptions of the same structure.
No sooner said than done. I took the most detailed description I had for a system that included everything (in my case, a distributed information system type II), and copied to other types. I reasoned that removing unnecessary (and other types of systems were a subset of a distributed IP type II) is easier than adding. Of course, this was not the case. It was necessary not only to delete too much, but also to add features of a particular type. As a result, a lot of time was spent on checking, re-checking and catching contradictions. In subsequent works, I began to act exactly the opposite - to describe the minimum necessary, adding specificity.
It took 5 days to create a threat model, and I proceeded to the second document.
Taught by bitter experience, first of all he created applications that users would have to fill out for themselves, and then proceeded to describe how to organize this filling.
The result is a ready-made methodology on threat models plus half of the applications.
7-9 day work
It was a time of euphoria, a plan in my head took shape, a purely mechanical work remained - all I could do was add applications and describe them correctly. The trouble came from no waiting, even two.
A sourceFor registration and re-registration of a pile of documents, I killed a significant part of the time. I wanted to do everything beautifully, so I immediately put down also internal links to sections and external files. Of course, as soon as there was a need for corrections (insert a new application, rewrite the document, etc.), all of this entailed reworking the entire design.
I do not remember what I was thinking then, but it seemed to me so important that after each structural change I was engaged in the design and rearrangement of links. Probably, it seemed to me that this change would definitely be the last, I will now quickly redo it and go to another to study.
With the acquisition of experience, I began to make colored plugs. Reference to
section 4 ,
annex 5 (track number) , etc.
The second misfortune was the terminology. Agreement on terms and definitions for all documents took a lot of time. Constantly had to scour the pages to clarify one or another formulation (I did everything on one monitor, and, believe me, it was not easy). This is an inevitable evil. Gradually, your vocabulary will replenish the corresponding burden of clericalism, and most definitions will be coordinated.
On the ninth day of work, everything was ready - two recommendation files with attachments. It remained to finish the little things.
10 day work
Having completed the trifles, I decided to re-read everything once again - correct errors, catch small shoals, etc. And here I wanted to do my job even better, to make it clearer. I decided to reflect in the description of the threats information from the summary tables (all these “threat realization is unlikely”). What for? Why? Here, I wanted.
I began to add, one began to cling to the other, and here the resulting tables would be nice to fix ... It seemed to become more beautiful, but the task of proofreading was completely failed. Therefore, do not strive for perfection, something can be improved endlessly, but it is unlikely anyone will appreciate it.
And time and effort must be left for proofreading. That is why the optimal number of people in a team is two. No more worth it. When after six months, a similar task for education was solved by five people, we killed a lot of time for coordination, grinding in parts written by different people, common terminology, proofreading, etc.
A sourceIf you are a titan of thought, then you can try working alone. But keep in mind that when you write 500,000 characters, your eyes will become blurred and it will seem that you are reading one thing, but in fact something completely different is written. Funny and sad.
I passed the job on time and went to bed. Later it was necessary to coordinate the documents with the regulator and correct the errors. As a result, these recommendations are widely distributed and some parts are present in the vast majority of sets of documents on personal data. After I did a similar job for education and nuclear energy. But that's another story.
PS A brief reminder for the brave
- Read the technical task.
- Do not disturb the sequence of work stages.
- Inside the stage, move from the result to the methodology, and then to the definitions.
- Supplementing small is easier than cutting large.
- Make the design last.
- Links inside the document put down on the penultimate step.
- Spend time re-checking.
A source