Data Governance - 1 - Data Roles

 

(Source: Imperva)

Intro

Việc collect data, xử lý, làm report, dashboard, trích xuất thành tri thức... thực tế không xa lạ gì với một Security Analyst . Khi triển khai SOC cho khách hàng, tôi cũng đã thực hiện qua gần hết tasks này, từ việc collect, chọn giải pháp - kiến trúc (2 tasks này chủ yếu sếp cũ của tôi làm =]] ), rồi sau đó tìm hiểu, triển khai, lập trình, tích hợp, vận hành... Vì vậy, khi tham gia vào 1 dự án tư vấn Data Governance, tôi thấy nhiều thứ rất quen thuộc, nhưng một số thì khá xa lạ; lại thêm một số tasks bao gồm nguyên domain Data Security được phân công cho Security team cũng như Data Governance là chủ đề lớn trong CISSP Domain 2 - Asset Security.

Quen thuộc là vì các data processing, data collect, data retention, data lifecycle management phases... đều là những công việc cần thiết của 1 SOC team, trong đó phần thể hiện rõ nhất theo tôi là của Security Analysts. Xa lạ vì có thể, sau khi GDPR ra đời, có thể các công ty tư vấn đã tạo dựng nên các framework, guidelines, trong đó có việc định nghĩa và tổ chức Data team, và còn hơn thế, có 1 C-Level trong BOD được gọi là Chief Data Officer (CDO). Khác và lớn hơn về quy mô so với đội ngũ Blue Team // Analysts mà tôi từng tham gia. 

Chuyện tiếp theo, khi tìm hiểu về CISSP Domain #2, tôi đọc thấy khá nhiều thông tin khá thú vị về việc tổ chức 1 Data team trong đó CDO là người đứng đầu. Sẽ có nhiều trường phái khác nhau vv tổ chức nhưng về cơ bản sẽ có các "roles" mà tôi sẽ đề cập sau.

Vì 2 lý do này tôi quyết định notes vài dòng về Data Governance sau khi tìm hiểu, cũng là để tổng hợp, tham khảo lại khi cần thiết.

Next Article > Data Roles

Chủ đề đầu tiên của loạt bài này có lẽ là về các Data Roles của chủ đề Data Governance. Không chỉ là 1 team, mà sẽ có lúc là 1 Commitee, bao gồm Business Owners, IT, MIS Team.., tham gia với vai trò đứng đầu hiển nhiên là CDO. Vậy DS roles này tiêu biểu gồm:

• CDO (cũng là 1 title)
• Data Owner (xem chi tiết ở dưới)
• Data Steward: 
• Quản gia data. 
• Giống như tên gọi, Quản gia sẽ được Data Owner ủy thác để làm 1 số công việc liên quan data hàng ngày. 
• Tuy nhiên, phê duyệt cho 1 nhóm người dùng mới có quyền truy cập, chỉnh sửa data... thường vẫn là việc của Data owner. 
• Data User: 
• Thao tác, thêm xóa sửa, nhất là query data.
• Data Custodian: Chủ yếu liên quan kỹ thuật, và do các IT Engineers đảm nhận theo các title khác nhau (??!!?)

Các IT titles có liên quan Data Roles

• Security Professional (hiểu rõ các security frameworks nói chung).
• IT Administrator: Thực hiện phân quyền, quản trị ứng dụng... theo delegation của System Onwer với sự phê duyệt/decide của Data Owner.
• DBA (~ IT Admin)
• MIS Team (theo cách gọi của 1 số cty): Data Analyst, Data Engineer, Data Scientest, ML Engineer

Data Owner

• Chủ sở hữu data, cũng có nghĩa là chịu trách nhiệm chính (liable) cho tất cả issues, operations liên quan data. 
• Vì vậy thường Data owner là CEO, President, hoặc là 1 Department head (chương 5, trang 204 của CISSP Study Guide, 9th edition). VD: CHRO hoặc HR Director là Data owner của thông tin nhân sự. 
• Data owner cũng sẽ chịu trách nhiệm classify cũng như label data do bản thân quản lý (own). Dựa vào classification và labeling, tổ chức sẽ áp dụng (implement) các security controls phù hợp (vd PCI-DSS có yêu cầu các controls/requirements liên quan credit card).
• "Establishes the rules for appropriate use and protection of the subject data/information (rules of behavior)" (cũng là AUP Acceptable Use Policy).
• "Provides input to information system owners regarding the security requirements and security controls for the information system(s) where the information resides". Vì vậy, "Owners may be liable for negligence if they fail to perform due diligence in establishing and enforcing security policies to protect and sustain sensitive data." (trang 204, Chương 5, CISSP Study Guide, 9th ed.)
• Data owner chịu trách nhiệm quyết định / phê duyệt (decide) quyền truy cập data phù hợp.
• Data owner thường cũng là System//Asset owner vì bản chất data quan trọng hơn là "hệ thống". 
• Tuy nhiên, System Owner có nơi là IT Department Head (DH), tách biệt với Data Owner. Khi đó Data Owner chịu trách nhiệm input cho việc tạo ma trận phân quyền truy cập system với các user roles khác nhau.

(còn tiếp)

Security Awareness - Phishing Simulation - Vài lưu ý khi gửi email phishing

 

Vài lưu ý khi gửi email phishing

1) Mail server gửi phishing: phải được cấu hình DNS, MX, TXT, SPF, PTR, đặc biệt là SPF. 

2) MS 365 hình như giới hạn số lượng email nhận từ 1 public IP xác định. Do đó phải có nhiều server IP sẵn sàng gửi spam/phishing emails.

3) Trên MS 365 nên config allow sẵn source address // sender addresses và/hoặc DS IP không bị blacklisted.

4) Thử nghiệm 1 nhóm nhỏ trước khi thực hiện nhóm lớn. Recon email nhận càng nhiều càng tốt. Chú ý active/inactive addresses.

5) Nên có nhiều content email template. 2 người cạnh nhau nên nhận email và phishing site khác nhau.

6) Content nên liên quan thứ gì đó hot trong cty, theo mùa, vd lương thưởng. Trường hợp phishing user pass, thì nên clone trang login MS 365.

7) Nên thuê ngoài, vd service của KnowBe4.

8) Thực hiện giả lập phishing trước awareness training.

Splunk - Hiệu chỉnh height và width aka tỷ lệ giữa các panels trên cùng row của 1 Splunk Dashboard

 

Chỉnh timechart panel có width =70% và stats panel có width = 30%

Kết quả:

Cách thức: 

* thông qua Edit Source của Dashboard  (sub url /editxml).

* 1) Gán id cho tất cả panel của row cần hiệu chỉnh width

Từ các <panel> thành <panel id="panel1"> .... </panel> <panel id="panel2">...<panel> 

* 2) Bổ sung 1 panel logic $alwaysHideCSS$ mới:

    <panel depends="$alwaysHideCSS$">

      <html>

        <style>

          #panel1{

            width:70% !important;

          }

          #panel2{

            width:30% !important;

          }

          </style>

      </html>

    </panel>

[System] Config postfix giới hạn tốc độ email được gửi đi

 

Giới hạn việc deliver email gồm 2 thông số:

smtpd_client_message_rate_limit 

The maximal number of message delivery requests that any client is allowed to make to this service per time unit, regardless of whether or not Postfix actually accepts those messages. The time unit is specified with the anvil_rate_time_unit configuration parameter.

By default, a client can send as many message delivery requests per time unit as Postfix can accept.

To disable this feature, specify a limit of 0.

WARNING: The purpose of this feature is to limit abuse. It must not be used to regulate legitimate mail traffic.

This feature is available in Postfix 2.2 and later.

Example:

smtpd_client_message_rate_limit = 1000

anvil_rate_time_unit (default: 60s)

The time unit over which client connection rates and other rates are calculated.

This feature is implemented by the anvil(8) service which is available in Postfix version 2.2 and later.

The default interval is relatively short. Because of the high frequency of updates, the anvil(8) server uses volatile memory only. Thus, information is lost whenever the process terminates.

Specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is s (seconds).

(Trích từ https://www.postfix.org/postconf.5.html)

=> Để tối ưu cho việc gửi mail, có lẽ nên thiết lập tốc độ gửi = 2-5 emails/phút do MS 365 kiểm soát, giới hạn gửi mail từ 1 IP cố định. Và có lẽ nên setup time unit theo phút, hơn là 3600s // 1 giờ.

smtpd_client_message_rate_limit = 5

anvil_rate_time_unit = 60

 

Splunk app UFMA - Forwarder Summary - Vài Issues liên quan Missing Forwarders hoặc Forwarders' Statistics

" Chủ yếu liên quan cách khai thác sd Splunk UFMA app.

1) Missing Forwarders hoặc Số lượng Forwarders hiển thị chưa đầy đủ ở dashboad Forwarder Summary

=> Giải pháp: truy cập Rebuild Asset Table http://localhost:8000/en-US/app/UFMA/rebuild_asset_table và run query anyway. Kết quả: http://localhost:8000/en-US/app/UFMA/forwarder_summary

2) Issue "We've identified a potential security risk" ở Dashboard "Rebuild Asset Table" 

=> Do outputlookup là splunk command có rủi ro cao. Cần ktra kỹ trước khi thực thi (từ các saved query). Bỏ qua và tiếp tục thực thi query này (anyway) => Xem http://localhost:8000/en-US/app/UFMA/rebuild_asset_table

3) Forwarder Summary - Forwarder Details trống rỗng 

=> Do keywords đòi hỏi phải có thông tin splunk deployment server => Bỏ text pattern deployment_server="$deployment_server$" này khỏi splunk keywords. Kết quả tại dashboard Forwarder Summary http://localhost:8000/en-US/app/UFMA/forwarder_summary phần Details sau khi update keywords: 

4) "This dashboard version is missing. Update the dashboard version in source."

=> Chỉnh source của dashboard, từ <form> thành <form version="1.0"> hoặc <dashboard> thành <dashboard version="1.0">. hình minh hoạ:

Save dashboard tương ứng và issue thông báo này sẽ biến mất.

The 2022 Ransomware Survival Guide

    

Quan trọng nhất vẫn là steps Before the attack.

Before the attack

• Back up and restore
• Update and patch: Keep operating systems, security software (AV / Endpoint Protection Software), applications and network hardware patched and up to date.
• Invest in robust people centric security solutions (#Me: e.g. SIEM, email security solutions...)
  • Employee training and awareness... people should know what to do, what not to do, how to avoid ransomware and how to report it....
• Plan your response

During & After the attack 

gồm các việc:

* Call law enforcement

* Disconnect from the network

* If the ransomware has already made its way to a server, the security team should isolate it as quickly as possible and map out a response.

* Implement your planned response (thực hiện theo Plan đã lập trong Before the attack)

* ... * Restore from backup

* Cleanup

* Review and reinforce > thực hiện 1 top-to-bottom security assessment.

* Post-mortem review > để xác định nguồn gốc, nguyên nhân lây nhiễm.

* Assess user awareness & Education and training

* Phishing simulation

* Reinforce your technology defences (~ cải tiến công nghệ)

* VD: SIEM > SOC > SOAR

* Secure email GW: hệ thống là những tuyến phòng thủ đầu tiên; con người là tuyến cuối cùng nhưng phải mạnh mẽ nhất (Make your people a strong last line of defence)

* People should know what to do, what not to do, how to avoid ransomware and how to report it. 

* If anyone receives a ransomware demand, they should know to immediately report it to the security team...

 

Plan your response

* "containment and recovery"

* "Critical questions such as: who needs to be informed, how to maintain communications, and how much are you willing to pay (if you’re willing to pay at all) are harder to answer in real time. This pressure creates potential bottlenecks in decision-making and leads to costly delays. Should you decide to pay the ransom, you’ll need to map out an appropriate process that includes key executives, operational staff and legal counsel."

* Response team

* Maintain the Vision using a separated Log System

* Communication 

* ... 

(Nội dung và hình: tham khảo từ Proofpoint - The 2022 Ransomware Survival Guide) 

System Hardening - Checklist cơ bản của 1 Window server

 

1) AV enabled

2) Patches

3) Account Policies

4) Logging 

4.1) Audit Policy

4.2) A remote logging software. E.g. Splunk Forwarder

4.3) Sysmon

4.4) A FIM Agent 

    E.g. https://docs.rapid7.com/insightidr/file-integrity-monitoring/ 

4.5) NTP

5) Turn off unnecessary Windows Features & Services

5.1) Server service?