다양한 metric의 필요성
얼마 전 신규 보안 제품 활용 교육 의뢰가 있었다. 엘라스틱 기반으로 개발했다는 설명을 듣고 어렵지 않겠다 싶어 수락. 그런데 제품을 살펴보니 데이터 집계 유형이 'Count' 밖에 없네? 같은 데이터를, 형태를 바꿔가며 다양하게 바라보는 과정을 거치면 자연스럽게 데이터에 대한 이해도를 높일 수 있다. 응답코드 500 상태의 로그 Count와 변수
데이터 분석 관점의 로그 분석 분야에 관심 많습니다.
얼마 전 신규 보안 제품 활용 교육 의뢰가 있었다. 엘라스틱 기반으로 개발했다는 설명을 듣고 어렵지 않겠다 싶어 수락. 그런데 제품을 살펴보니 데이터 집계 유형이 'Count' 밖에 없네? 같은 데이터를, 형태를 바꿔가며 다양하게 바라보는 과정을 거치면 자연스럽게 데이터에 대한 이해도를 높일 수 있다. 응답코드 500 상태의 로그 Count와 변수
IT 분야에서 남다른 통찰력을 보여주는 박상민님의 글 중 일부. 문제를 찾아서 해결하려는 의지를 버리고 경제 환경(economic environment)이 변하는 흐름을 찾아내 이 변화가 여는 기회를 포착하는 것 자신이 원하는 문제가 아닌, 사회가 원하는 문제를 해결해야 스타트업 성공 가능성이 높아진다는 얘기. 그럼 구글이나 페이스북은 다 뭐람? 모두 자신이 원했던 문제에
살다살다 내가 내 돈 주고 이런 책을 사보는 날이 오는구나(..) 구글 및 텐센트에서 자연어 처리 및 검색 전문가로 일했던 우쥔의 2014년 저서. 중국 IT 스타는 앤드류 응밖에 몰랐는데, 중국의 IT 파워를 새삼 느끼게 해준 책. 그래봐야 트럼프 손바닥 '기계학습과 침입탐지: 문법 추론 결과'를 보다 멘붕에 빠진 후,
아마존이 인증, 알람 등 일부 X-Pack 상용 기능이 포함된 엘라스틱서치 배포판을 공개해서 이슈인 모양이다. 오픈소스 생태계에 이바지한다는 명분을 내세우고 있지만, AWS 내에서 엘라스틱 사용 비중이 커지니까 고객 충성도도 높이고 신규 고객도 더 늘려보겠다는 목적으로 저지른 모양. 의견은 반으로 갈리는 중이다. 대기업 횡포라며 베조스를 씹는 사람도 있고, 사용자 입장에서 땡큐라는
인터넷 끊으면 됨. 피싱이고 APT고 랜섬웨어고 뭐고 다 인터넷만 끊으면 걱정 끝. 이후엔 톰아저씨만 조심하며 된다. 진짜로(..) 피싱 등으로 직원 PC가 털린 후 고객정보 유출로 이어진 동종 업계 사례 때문에 고민인 분을 만났다. 근데 이분 본업은 DBA라고.-_- 내부에서 간단하게 위험을 모니터링할 수 있는 방법을 알려달라고 하는데, 네트워크 통신량같은 거 보는
다음은 단골 강의 주제인 secure 로그 프로세스 발생 통계. 발생한 프로세스의 종류는 6개. 사전 분석 과정에서는 분명 7개였는데, sudo 프로세스 어디갔지?-_- grok 필터에 사용된 정규표현식을 살펴봤다. login과 sshd 프로세스로만 테스트했구나. 그래도 다른 프로세스는 다 추출됐는데 왜 sudo만 빠졌을까? 검사 대상에 sudo 프로세스도 포함시켜봤다. 다른 프로세스는 이어지는 문자열과 하나의 '공백&
보안
다니던 회사가 보안인증 심사 대상에 포함됐다던지 하는 이유로 하루 아침에 보안 담당자가 되신 분들이 업무의 어려움, 특히 제품 선정 등의 어려움을 토로할 때가 있다. 그럴 때 두 가지 기준만 세워두면 기술 배경 몰라도 보안 그리 어렵지 않다는 얘기를 건넨다. 그간 기술자로 일하면서 쪽팔리지 않으려 발버둥치다 보니 자연스럽게 갖게 된 기준.
mysql
MySQL은 POSIX 기반 정규표현식을 지원한다. 전방탐색 등의 고오급 기능을 지원하지 않는다는 얘기. 그래서 문제 발생. 다음은 SNORT DB에서 특정 탐지로그를 발생시킨 패킷 페이로드 조회 결과. 해당 로그를 텍스트로 옮기면 빈 줄 포함, 총 5개의 줄로 구성되어 있다. 줄바꿈 문자(0D0A)가 반영된 결과. 이게 왜 문제냐면 한 줄 단위가 아니기
'|' 기호를 이용해서 발생시간, 출발지, 목적지, 출발지포트, 목적지포트, 공격명, 원본로그 필드를 구분하는 로그가 있다. 자고로 로그는 테이블 구조에 우겨 넣어서 분석해야 제 맛. 그런데 원본로그 필드가 3개로 나눠졌네? 로그를 다시 보니 OR 연산자로 사용된 '||' 기호가 확인된다. 결과적으로 원본로그가 3개 필드로 쪼개짐. 옛날 생각이 난다 처음 로그를 필드별로
보안
서울대 경제학과 이천표 교수의 2007년 저서. 제목이 너무 부럽다. 공부 열심히 하면 책 제목이 바뀜 그러니 학생은 닥공 그냥 경제학이 아니라 정보통신 경제학을 강의한다는 저자의 이력이 특이하다. 그리고 무엇보다 정보보안을 바라보는 경제학 교수의 관점이 재미있다. "기술 만능의 사고는 모든 관련자들로 하여금 안전성 확보를 위해 노력하도록 경제적으로 유인하는 것보다 좋은
키바나 기능 중에 'scripted field'라는 게 있다. 무엇에 쓰는 물건인가 싶어 찾아보니 '중요한 값을 스키마에서 별도 필드로 정의하지 못하였거나 또는 두 개 필드를 결합하여 단일 필드로 처리하고자 하는 경우'에 유용한 기능이라고. 로그스태시 연동할 때 깜박하고 로그 필드 정의 빼먹었다가 처음부터 다시 하는 불상사를 막을
트래픽을 분석하다 보면 종종 URL, HEX, BASE64 디코딩이 필요할 때가 있는데, 인터넷에는 관련 서비스를 제공해주는 고마운 분들이 정말 많다. 그런데 인터넷이 안 된다면? 이럴 때 LogParser를 사용하면 매우 편하다. 간단히 소개하자면 텍스트 기반 로그 및 윈도우 이벤트 로그 등을 별도의 전처리를 하지 않고도 SQL로 분석할 수 있게 해주는 정말 기똥찬