Всем привет! Так исторически складывается, что когда вы разрабатываете государственные системы, в большинстве случаев требуется написание большого количества документации, а в данной ситуации такая документация еще и требует соответствию ГОСТ.

Хотелось бы вспомнить одну из парадигм Agile " Работающий продукт важнее исчерпывающей документации ", но в данном случае это не наша история, поэтому сегодня поговорим немного о ГОСТах.

Стоит сделать небольшое лирическое отступление и начать с формального определения:

Первый и самый логичный вопрос, который возникает, когда видишь этот документ в списке требований от Заказчика.

Изначально пойдем простым путем и поищем определение на просторах интернета.

Как итог – определение Роскомнадзора используется практически везде.

Звучит оно так:

Модель угроз и нарушителя – это «совокупность предположений о возможных угрозах и возможностях нарушителя, которые он может использовать для разработки и проведения атак в рамках разрабатываемой системы».

Теперь разберёмся с основной целью написания документа (оставлю небольшую ремарку: в целом, модель нарушителя – это больше описание «бумажной безопасности»).

Для более точного понимания обратимся к нормативной документации, а именно – методике Федеральной службы по техническому и экспортному контролю (ФСТЭК). Получим следующее определение:

«Целью моделирования угроз безопасности информации является выявление совокупности условий и факторов, которые приводят или могут привести к нарушению безопасности обрабатываемой в системах и сетях информации (нарушению конфиденциальности, целостности, доступности, неотказуемости, подотчетности, аутентичности и достоверности информации и т.д., а также к нарушению или прекращению функционирования систем и сетей)»

Если вы впервые сталкиваетесь с требованиями информационной безопасности, то скорее всего вам будет «очень интересно, но ничего непонятно».

Будем проще – данная модель содержит перечень возможных нарушителей, которые могут скомпрометировать/навязать/испортить информацию в разрабатываемой системе; список угроз в соответствии с классом вашей системы и описание некоторых последствий, которые могут появиться, если нарушитель все-таки украдет вашу информацию.

Всем привет! Сегодня хотелось бы поговорить про такую тему, как оценка времени разработки. Тема достаточно интересная т.к. нет какого-то обобщенного стандарта оценки.

Когда-то это было одной из первых моих задач на работе, и когда мне впервые дали требования и сказали "Оцени сколько нужно времени". Естественно первый мой вопрос был "А как ?". Я тогда и представить не могла, как можно оценить то, что не сделано и непонятно, как будет реализовано...

Какие есть подходы и как аналитику оценить задачу? На этот вопрос постараюсь ответить дальше

Спустя год своей работы на позиции системного аналитика, я иногда вспоминаю, как все начиналось. Сегодня хотелось бы поговорить о сложностях этой роли, которые возникают в самом начале.

Но что делать, когда ты junior, но тебе очень хочется стать специалистом в данной области?

 Курсы не помогают

Я выбрала такой подзаголовок, потому что это будет самая основная мысль этого раздела. По правде говоря, курсы не помогают. Для аналитика безусловно важно стоять на двух ногах «теории» и «практике». Но без практики на одной теории далеко не уедешь. И чаще всего, релевантный опыт аналитика – это именно боевой опыт на проектах. Поэтому, ты можешь бесконечно много читать, как проектировать REST, но если ты так ни разу пока его не проектировал, то шансов, что работодателя это устроит, честно говоря, маловато.

 Что же делать?

И вот мы подходим к самой интересной части. Представьте, что у вас есть технический бэграунд, вы в прошлом программист, и вам повезло, что нашлась компания, которая в вас поверила и понимая все риски, всё-таки решила вас взять.

Вы попадаете на свой первый проект, который начинаете с нуля. Количество ваших боевых знаний примерно на уровне – где-то читал, что-то видел, а к вам постоянно идут люди и задают вопросы, на которые увы, ответов вы не знаете.

Зачастую, все работодатели при поиске данного специалиста заинтересованы в том, чтобы человек был с опытом. Что крайне логично, потому что данная роль предполагает определенный уровень ответственности.

Опыт желательно от 3 до 6 лет, прекрасно если работал на банковских проектах. Тогда им уже точно ничего не страшно.

В мире IT аналитики я всего год. Но даже за такой небольшой промежуток времени, при поиске работы столкнулась с настолько разным и размытым пониманием понятия "Системный аналитик", что сегодня хотелось бы немного разобраться, что же это за неведомый науке зверь.