Cách khắc phục các lỗ hổng phổ biến trong chuỗi cung ứng
Từ góc độ vòng đời phát triển phần mềm (SDLC), bảo mật là khía cạnh quan trọng nhất của doanh nghiệp, vì các lỗ hổng bảo mật gây ra rủi ro cho các tổ chức lớn và hướng tới người dùng. Do đó, các doanh nghiệp đầu tư mạnh vào việc ưu tiên bảo mật phần mềm.
Là một doanh nghiệp hoặc nhóm tập trung vào quyền riêng tư có thể mang lại những lợi ích đặc biệt nói chung. Khách hàng đánh giá cao các tính năng bảo mật phần mềm mà doanh nghiệp đang xây dựng và nâng cao cũng như khả năng sử dụng. Tuy nhiên, việc đạt được cột mốc quan trọng này cần được xem xét cẩn thận với những hàm ý nghiêm ngặt đối với các hướng dẫn và phương pháp hay nhất về bảo mật SDLC.
SDLC chứa các điểm kiểm tra bảo mật để bảo vệ tính bảo mật, tính khả dụng và tính toàn vẹn của toàn bộ hệ thống và dữ liệu trong đó. SDLC được hợp nhất với mô hình hoàn thiện phần mềm OWASP (OWASP SAMM) có thể giúp xây dựng và triển khai lộ trình chiến lược toàn doanh nghiệp để bảo mật ứng dụng.
Chuỗi cung ứng phần mềm là gì?
Chuỗi cung ứng phần mềm là một nguyên tắc bao gồm các nhóm (cả bên trong và bên ngoài), các phương pháp, công cụ và các phương pháp hay nhất để đưa tạo phẩm phần mềm trực tiếp từ thiết kế đến triển khai.
Trong thời gian gần đây, hầu hết các dịch vụ và trải nghiệm kỹ thuật số đổi mới và đột phá được phát triển bằng cách sử dụng phần mềm nguồn mở bởi các nhóm làm việc từ xa.
Các thư viện mã nguồn mở thu hút các nhà phát triển bằng các tính năng nổi bật của chúng, cho phép các kỹ sư đẩy mạnh quá trình phát triển bằng cách giảm thời gian đưa ra thị trường và các tác động về chi phí.
Nhưng các lỗ hổng và sự phức tạp xuất hiện khi sử dụng phần mềm nguồn mở do thiếu kiểm soát đối với mã nguồn và các bản phát hành tính năng theo thời gian với các bản vá lỗi và chúng có nguy cơ bị tấn công chuỗi cung ứng nguồn mở .
Mã được phát triển không đầy đủ với các bí mật được mã hóa cứng và cơ sở hạ tầng được kiến trúc lỏng lẻo dễ bị tấn công thường xuyên.
Các lỗ hổng phổ biến nhất
Các lỗ hổng phần mềm phổ biến trong các tổ chức thuộc mọi cấp độ. Các công ty mới thành lập có nhiều khả năng trở thành nạn nhân của các cuộc tấn công như vậy khi họ tập trung vào việc đưa các tính năng mới ra thị trường theo thời hạn chặt chẽ. Thật không may, những lần phơi bày này không xuất hiện trên tiêu đề để nâng cao nhận thức cho cộng đồng công nghệ. Hãy thảo luận về một số sự cố lịch sử phổ biến và có ảnh hưởng nhất.
Tại một thời điểm, tin tức nóng hổi về cuộc tấn công chống lại SolarWinds đã làm rung chuyển thế giới công nghệ. Sự kiện này đã trở thành một ví dụ điển hình về sự nguy hiểm của các hoạt động bảo mật không đầy đủ.
Thảm họa nổi lên khi một nhân viên thực tập không đặt được mật khẩu phức tạp. Những kẻ tấn công đã thâm nhập vào hệ thống SolarWinds thông qua tổ hợp mật khẩu yếu bằng phương pháp gọi là rải mật khẩu và quản lý để đẩy phần mềm độc hại qua cửa hậu vào tất cả các doanh nghiệp phụ thuộc. Cuộc tấn công chuỗi cung ứng dựa trên danh tính đã cập nhật máy chủ cập nhật SolarWinds.
Thực thi các chính sách mật khẩu mạnh trên hệ thống với các lớp bảo mật bổ sung như MFA có thể tránh được thảm họa.
Một vụ việc tương tự cũng xảy ra tại cơ quan cấp chứng chỉ số của Chính phủ Việt Nam. Những kẻ tấn công đã vượt qua tường lửa của trang web và chèn các tệp trình cài đặt bổ sung vào các ứng dụng trình cài đặt VGCA, đây là các ứng dụng dành cho khách hàng do VGCA cung cấp để cung cấp chữ ký số.
Hoạt động tổng thể đã thành công vì những kẻ tấn công đã tìm thấy lỗ hổng trong thiết kế trang web vì thiết kế tổng thể có một chút sai sót. Cuộc tấn công cửa sau có thể tránh được với các hạn chế nghiêm ngặt về tường lửa, kiểm soát truy cập và quyền đặc quyền.
Để biết một ví dụ khác về cách các lỗ hổng có thể làm tê liệt hệ thống, hãy xem xét Bitcoin. Bitcoin có thể dễ dàng bị lộ và bị đánh cắp nếu nhà cung cấp dịch vụ không duy trì các nguyên tắc bảo mật.
Copay, một ví Bitcoin, đã bị tấn công chuỗi cung ứng khi một ứng dụng di động lưu trữ ví bitcoin gặp lỗi. Lỗi trong kiến trúc xuất phát từ lỗ hổng gói của trình quản lý gói nút công cụ Javascript nguồn mở (NPM). Phiên bản bị lỗi này đã được công khai và cho phép tin tặc thay đổi ứng dụng để tải mã được cấu trúc lại và có quyền truy cập vào thư viện JS.
Lỗi này có thể đã được phát hiện và khắc phục bằng các công cụ quét lỗ hổng trong quy trình triển khai và kiểm soát phiên bản.
Các bộ phận di chuyển để quản lý chuỗi cung ứng phần mềm
Một kế hoạch chi tiết rõ ràng tuân theo tài liệu vững chắc, an ninh mạng, khắc phục rủi ro và các phương pháp hay nhất về quản lý sẽ loại bỏ các lỗ hổng tiềm ẩn và tăng cường bảo mật chuỗi cung ứng phần mềm. Các tổ chức phải điều chỉnh các nguyên tắc kỹ thuật “an toàn theo thiết kế” và chiến lược thay đổi sang trái để thiết lập chuỗi công cụ DevSecOps toàn diện.
Giai đoạn 1: Kiến thức viết mã an toàn
Trước hết, các doanh nghiệp nên áp dụng các chương trình học tập và phát triển độc quyền về quản lý rủi ro và bảo mật. Khi các nhóm phát triển gấp rút cải thiện kỹ năng kỹ thuật của họ, một mục tiêu chung mà các doanh nghiệp nên chia sẻ là cách giúp các nhà phát triển trở thành nhà vô địch về bảo mật.
Đánh giá lỗ hổng ứng dụng và các khóa học bảo mật là cần thiết để giữ cho các kỹ sư phù hợp với các mục tiêu kinh doanh.
Giai đoạn 2: Mô hình hóa mối đe dọa
Việc xác định các rủi ro bảo mật trước khi quá trình phát triển và hoạt động bắt kịp là điều cần thiết. Giai đoạn này đảm bảo chiến lược thiết kế và phát triển tổng thể phù hợp với các tiêu chuẩn bảo mật của tổ chức.
Mô hình hóa mối đe dọa cung cấp cho các tổ chức một cách tiếp cận có cấu trúc để xác định, phân tích, đánh giá và giảm thiểu rủi ro ở giai đoạn phát triển ban đầu. Các mô hình mối đe dọa cho thấy lời hứa liên quan đến bảo mật bằng cách cho phép các nhà phát triển và kiến trúc sư suy nghĩ từ quan điểm của kẻ tấn công, cho phép họ lập kế hoạch và thiết kế một hệ thống an toàn.
<?xml version="1.0" encoding="utf-8"?>
<KnowledgeBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Manifest name="Basic threat modelling design" id="5d3b996b-bac2-8cf6-3b39-617bb67bf042" version="4.1.0.11" author="TwC MSEC" />
<ThreatMetaData>
<IsPriorityUsed>true</IsPriorityUsed>
<IsStatusUsed>false</IsStatusUsed>
<PropertiesMetaData>
<ThreatMetaDatum>
<Name>Title</Name>
<Label>Title</Label>
<HideFromUI>false</HideFromUI>
<Values>
<Value />
</Values>
<Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
<AttributeType>0</AttributeType>
</ThreatMetaDatum>
<ThreatMetaDatum>
<Name>UserThreatShortDescription</Name>
<Label>Short Description</Label>
<HideFromUI>true</HideFromUI>
<Values>
<Value>Threat modeling is critical and mandate phase in secure software development</Value>
</Values>
<Id>ac0f9ea8-aed5-4d95-4ce9-6787124d7b48</Id>
<AttributeType>1</AttributeType>
</ThreatMetaDatum>
<ThreatMetaDatum>
<Name>UserThreatDescription</Name>
<Label>Description</Label>
<HideFromUI>false</HideFromUI>
<Values>
<Value />
</Values>
<Id>5d3b996b-bac2-8cf6-3b39-617bb67bf042</Id>
<AttributeType>0</AttributeType>
</ThreatMetaDatum>
<ThreatMetaDatum>
<Name>Priority</Name>
<Label>Priority</Label>
<HideFromUI>true</HideFromUI>
<Values>
<Value>High</Value>
<Value>Medium</Value>
<Value>Low</Value>
</Values>
<Description>Priority</Description>
<Id>ac0f9ea8-aed5-4d95-4ce9-617bb67bf042</Id>
<AttributeType>1</AttributeType>
</ThreatMetaDatum>
</PropertiesMetaData>
</ThreatMetaData>
<GenericElements>
<ElementType>
<Name>Threat modeling Process</Name>
<ID>GE.P</ID>
<Description>General approach to define a threat model</Description>
<ParentElement>ROOT</ParentElement>
<Image>Image_ref</Image>
<Hidden>false</Hidden>
<Representation>Ellipse</Representation>
<StrokeThickness>0</StrokeThickness>
<ImageLocation>Centered</ImageLocation>
<Attributes>
<Attribute>
<Id>002864b3-9a4e-4d21-8a4d-8aea1d2e3056</Id>
<IsInherited>false</IsInherited>
<IsOverrided>false</IsOverrided>
<Name>codeType</Name>
<DisplayName>Code Type</DisplayName>
<Mode>Dynamic</Mode>
<Type>List</Type>
<Inheritance>Virtual</Inheritance>
<AttributeValues>
<Value>Not Selected</Value>
<Value>Managed</Value>
<Value>Unmanaged</Value>
</AttributeValues>
</Attribute>
</Attributes>
</ElementType>
</StandardElements>
</KnowledgeBase>
Mã nên được bắt buộc để xem xét mã bởi các đồng nghiệp. Cho phép đánh giá qua vai và qua email cho phép các nhóm phát triển phát hiện lỗi và khiếm khuyết trong giai đoạn phát triển ban đầu.
Sự chậm trễ và lỗ hổng bảo mật có thể xuất hiện trong mã ngay cả khi đã cân nhắc cẩn thận và nỗ lực thủ công. Các lỗi phổ biến nhất bao gồm nếu có bất kỳ cấu trúc lập trình nào bị thiếu, mã tổng thể tuân thủ các tiêu chuẩn bảo mật và mã vượt qua kiểm tra gợi ý kiểu và xơ vải.
Đánh giá mã có sự hỗ trợ của công cụ ít bị lỗi hơn và tránh được các rủi ro về lỗ hổng. GitHub có thể chứng tỏ là một công cụ đáng tin cậy và hiệu quả để kiểm tra mã và đánh giá mã khi đang di chuyển, với tính năng kiểm soát phiên bản là một lợi thế bổ sung.
Giai đoạn 4: Quét qua các công cụ tự động
Tự động hóa việc xem xét mã trước khi hợp nhất vào bản gốc là vô cùng quan trọng. Việc không vượt qua các kiểm tra được xác định trước sẽ làm nổi bật các vấn đề trong mã và kích hoạt vòng phản hồi để các nhà phát triển tái cấu trúc và bảo mật toàn bộ cơ sở mã.
WhiteSource dành cho nhà phát triển, Codacy và Codecov là các công cụ đánh giá tự động có sẵn thông qua thị trường GitHub để nhanh chóng tích hợp vào cơ sở mã của bạn và đạt được các yêu cầu về ngăn xếp công nghệ. Các công cụ này sử dụng phương pháp dịch chuyển sang trái để quét và lập chỉ mục mã nguồn mở của tất cả các Kho lưu trữ GitHub hiện có.
Giai đoạn 5: Quét mã tĩnh và kiểm tra bảo mật
Việc tự động gỡ lỗi và đánh giá mã trong khi bỏ qua quá trình thực thi thông qua đường ống dẫn có thể mang lại hiệu quả trong giai đoạn xây dựng và triển khai. Các công cụ tự động hóa quy trình nâng cao, như Jenkins, được tải với một loạt các plugin đánh giá mã.
Các plugin đánh giá mã tĩnh như FindBugs thực hiện đánh giá và phân tích mã bằng cách chạy các kiểm tra và logic được xác định trước, trả về một tệp đầu ra. Jenkins có thể phân tích cú pháp tệp đầu ra từ công việc, đánh dấu các lỗi và liệt kê các cảnh báo gặp phải bằng cách thực hiện theo cách tiếp cận từ trên xuống ở cấp mã thư mục và trình bày tóm tắt chi tiết về phân tích tổng thể bằng đồ họa.
Mẫu mã:
trigger:
branches:
include:
- feature
- main
paths:
include:
- src/*
- tests/*
pool:
Image: 'centos/latest'
jobs:
- job: codereview
displayName: review and report
steps:
- checkout: self
lfs: true
- task: UsePythonVersion@0
displayName: 'Set Python version to 3.9'
inputs:
versionSpec: '3.9'
- script: pip3 install --user -r requirements.txt
displayName: 'Installing required dependencies'
- script: |
python -m behave --junitxml=./validation_test-checks.xml
displayName: 'Running behave tests'
- task: PublishBehaveResults@1
displayName: 'bumping out behave test results'
condition: passOrFail()
inputs:
testResultsFiles: '**/validation_test-*.xml'
testRunTitle: 'Publish behave test results for Python $(python.version)'
Lỗ hổng chuỗi cung ứng phần mềm là những con thú không thể tránh khỏi. Khi bị bỏ qua, chúng có thể phá hủy toàn bộ hệ thống, ảnh hưởng đến cả hoạt động kinh doanh và danh tiếng. SDLC bao gồm nhiều kỹ thuật và bộ công cụ để biến bảo mật thành một cột mốc quan trọng trong hành trình phần mềm.
Giai đoạn phát triển tổng thể phải tuân theo các giai đoạn nêu trên, bắt đầu từ hiểu biết về bảo mật, lập mô hình mối đe dọa, đánh giá mã ngang hàng, kiểm tra mã tự động, quét mã tĩnh và kiểm tra bảo mật.
![Dù sao thì một danh sách được liên kết là gì? [Phần 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)
