Одна из самых часто используемых техник при атаках — получение учетных данных из операционной системы. В этом можно убедиться, читая аналитические отчеты различных компаний: техника T1003 OS Credential Dumping в подавляющем большинстве случаев входит в ТОП-5. После проникновения в систему злоумышленникам необходимы учетки для перемещения по сети и доступа к конфиденциальной информации, а данная техника направлена на извлечение локальных и доменных учетных записей из системных файлов, реестра и памяти процессов.

В этой статье мы акцентируем внимание на своевременном выявлении подозрительной активности с помощью мониторинга ИБ и расскажем, как на основе событий штатной подсистемы аудита ОС обнаружить, что пытаются сдампить учетные данные в Windows. Логика детектирования будет представлена в общем виде по полям событий, а также в виде псевдокода, который можно адаптировать под синтаксис любой системы мониторинга. Ну и для возможности тестирования правил корреляции будут приведены краткая справка по атакам и способы их реализации.

Рассмотрим покрытие таких подтехник, как:

·       дамп процесса lsass.exe;

·       кража данных из базы SAM;

·       дамп базы NTDS;

·       извлечение секретов LSA;

·       получение кэшированных данных;

·       атака DCSync.

Начинаю серию статей, посвященных задачам аналитика на различных этапах создания программного обеспечения (ПО). В ходе наших бесед, мы рассмотрим, какие конкретные артефакты возникают после завершения каждого этапа, а также как правильно составлять эти артефакты.

Была у нас тут история, когда легкий перфекционизм помог привести в порядок конструкторскую документацию и регулярно экономить инженерам кучу дней на прохождение бюрократических процедур. В ее основе – создание системы управления расчетными данными и переход от трудночитаемых и трудноинтегрируемых отчетов Mathcad к гибкой связке Jupyter Notebook с Python и Teamcenter. Но основной рассказ будет про то, как преобразовывать и экспортировать математические формулы, таблицы и другие элементы из Jupyter в красивый и удобный вид.

Ни в форумах, ни в блогах, ни в России, ни в англоязычных ресурсах я не смог найти информацию о том, как логично упаковать всю релевантную фактуру в приятный технический документ. В книге М. Ильяхова «Пиши, сокращай» есть отдельная глава про дидактику, но там очень мало, вскользь и не совсем о том.

Еще есть ГОСТы 34 и 19 — там уже написано, из каких разделов должен состоять стандартизованный документ, но ведь кроме стандартизованных есть и другие документы — во всяком случае заказы на таковые ко мне приходили, — и каждый раз приходилось ломать голову.

В этой статье я расскажу об алгоритме процедурной генерации лабиринтов методом поиска в глубину (Randomized depth-first search with recursive backtracking).

Все мы думаем, что хорошо говорим и пишем на своём родном русском языке. Не зря же в конце концов мы столько учились, да и в деловой переписке у нас всё вроде бы вполне неплохо. Но знаете ли вы о том, что даже для написания IT-документации есть свои правила? Поэтому сегодня в блоге ЛАНИТ на Хабре мы поделимся знаниями о русском «документном» языке. 

Всем привет! Меня зовут Антон, я 9 лет занимаюсь документацией для программистов и год работаю техническим писателем в IT-департаменте Банка РНКБ. За это время у меня сложилось своё видение «хорошей» документации и методики её разработки, и я решил поделиться им с вами.

Планирую рассказать всё в двух статьях. Сегодня поговорим о документации для IT-департамента — той, которую распространяют в электронном виде, размещают на отдельном сайте и которой пользуются программисты, тестировщики, аналитики и руководители отделов. Помимо своего опыта, покажу примеры, статьи и исследования на тему ведения документации, которые помогли мне — и могут пригодиться вам.

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

Материала вышло многовато, поэтому разбил его на 2 части. В части 1 (этой статье) рассмотрим, почему и зачем вообще публичным API нужна документация, есть ли у нее какие-то отличия от документации внутренних API, а также проанализируем и детально разберем различные подходы к ведению такой документации, попутно познакомившись поближе с полезными инструментами.

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

Меня зовут Марина, я работаю техническим писателем в ГНИВЦ. Еще с детства я любила делать доклады в школе, а где все пишут доклады? Word! Именно с тех времен началась моя история дружбы с данной программой.

Сегодня я хочу поделиться с вами о работе перекрестных ссылок. Вроде бы ничего сложного, если бы не одно НО! Как раз об этом «НО» и будет моя статья.

Привет! Меня зовут Андрей Гладилин, я работаю в Swordfish Security над составлением технической документации для ИТ-решений. Завершая  предыдущую статью, мы обсудили преимущества и недостатки DocOps-подхода к разработке технической документации и немного поговорили о прикладной реализации этой парадигмы — Doc-as-code.

Позволю себе напомнить, что основная идея DocOps заключается в том, что создание технической документации осуществляется в тесном контакте с разработкой программного продукта и во многом «отзеркаливает» этапы последней — рабочие процессы максимально синхронизируются и объединяются в общую систему, широко применяется автоматизация рутинных операций и упрощается совместная работа, что позволяет повысить общую эффективность процесса.

Теперь перейдем к практической реализации DocOps-решения, которое мы начали обсуждать в первой части статьи.

Привет Хабр! Мы в SSP SOFT разрабатываем заказное ПО для ведущих российских банков и финтех-проектов. Системный аналитик (СА) — одна из ключевых фигур в проектных командах, и такие вакансии с грейдами сеньор, мидл и джун регулярно появляются в компании. Для технического интервью мы привлекаем внешних экспертов с компетенциями, которые максимально близки к предметной области проекта. Эта статья — наша версия на тему проверки опыта и навыков СА на собеседовании. Читайте и комментируйте ✍️.

Всем привет, меня зовут Женя Колесников, я из команды Yandex Infrastructure. Сегодня я расскажу, как мы пришли к написанию документации в концепции Docs as Code, придумали для этого набор инструментов, назвали его красивым именем Diplodoc и выложили в опенсорс — теперь вы тоже можете им воспользоваться.

Если вкратце, Docs as Code — это подход к написанию технической документации, который рассматривает её не как набор текстов, а как код. Исходя из этой концепции, к документации могут применяться все те же принципы, инструменты и процессы, что и к самому коду. Расскажу, как это происходит на примере Diplodoc — и чем он может облегчить вам жизнь.

Привет, Хабр! На связи снова Юрий Никулин. В первой части статьи я рассказывал, почему в Cloud.ru решили перейти на doc as code и какой технологический стек мы выбрали. В этой части поделюсь самим процессом — расскажу, как настраивали, тестировали и внедряли новую систему и что из этого вышло.

В данной статье собраны основные операции и алгоритмы работы, позволяющие повысить эффективность разработки документации в редакторе Microsoft Word как индивидуально, так и при командной работе.

Не рассматриваются подходы с использованием Markdown, Pandoc, Asciidoc и Confluence как более сложные и узкоспециализированные, а статью хотелось сделать доступной и понятной не только молодым людям, но и людям старших возрастов.

— Видишь суслика?

— Нет…

 — И я не вижу. А он есть!

Одним из мощных и удобных инструментов текстовых редакторов является скрытый текст. Этот инструмент имеется практически во всех редакторах. Самым популярным и совершенным редактором на данный момент является MS Word. Поэтому некоторые возможности скрытого текста рассмотрены на его примере.

Меня зовут Юлия Седова, и я представляю команду технических писателей ГК «Цифра». В рамках масштабной работы по повышению качества документации мы столкнулись с проблемой отсутствия культуры предварительного планирования трудозатрат технического писателя. В этой статье я хочу поделиться нашим решением проблемы.