Về Cải thiện Bảo mật với Steve Wilson

Steve Wilson là Giám đốc Sản phẩm của Contrast Security, với hơn 25 năm kinh nghiệm phát triển và tiếp thị sản phẩm tại các công ty công nghệ trị giá hàng tỷ đô la như Citrix, Oracle và Sun Microsystems. Trong AMA này, Steve cho chúng ta biết về bảo mật không máy chủ, bảo mật ứng dụng trong hệ sinh thái JAVA, SBOM và các phương pháp hay nhất. Chủ đề lười biếng này của Mónica Freitas, Steve Wilson, Zach Taylor, Victor de Avila, Jack Boreham và Sara Pinto xuất hiện trên kênh #amas chính thức của slogging và đã được chỉnh sửa để dễ đọc. Xin chào @channel, hãy cùng tôi chào đón vị khách AMA tiếp theo của chúng ta, Steve Wilson. Steve hiện là Giám đốc Sản phẩm của Contrast Security. Ngày nay nhóm của anh ấy chịu trách nhiệm về Kỹ thuật, Quản lý Sản phẩm và Thiết kế Sản phẩm cho tất cả các sản phẩm. Steve có hơn 25 năm kinh nghiệm phát triển và tiếp thị sản phẩm tại các công ty công nghệ trị giá hàng tỷ đô la như Citrix, Oracle và Sun Microsystems. Trước Contrast, Steve là Phó Chủ tịch Quản lý Sản phẩm của Citrix Cloud, nơi ông đã lãnh đạo việc chuyển đổi các sản phẩm Citrix từ sản xuất tại chỗ truyền thống sang SaaS.

Tại Oracle, ông đã lãnh đạo kỹ thuật cốt lõi cho dòng sản phẩm phần mềm quản lý hệ thống trị giá hàng tỷ đô la. Trong thời gian làm việc tại Sun Microsystems, Steve là thành viên ban đầu của nhóm phát triển hệ thống lập trình máy tính Java, bộ công cụ phát triển phần mềm được sử dụng rộng rãi nhất trong lịch sử.

Vui lòng hỏi Steve bất cứ điều gì về:

Xin chào Steve Wilson! Thật tuyệt khi có bạn cùng chúng tôi! Bạn có thể bắt đầu bằng cách cho chúng tôi biết một chút về nền tảng của bạn và cách bạn đến làm việc với Contrast Security?

Xin chào Mónica Freitas! Thật tuyệt vời khi được ở đây. Trước tiên, tôi muốn bắt đầu bằng cách cảm ơn HackerNoon đã cho tôi tham gia AMA của họ và tôi mong được trả lời các câu hỏi của bạn.

Tôi là Giám đốc Sản phẩm của Contrast Security, công ty đi đầu trong lĩnh vực bảo mật ứng dụng cho phép các nhà phát triển bảo mật như mã của họ. Nền tảng của chúng tôi cung cấp cho các nhà phát triển các giải pháp bảo mật tự phục vụ để nâng cao hiệu quả trong toàn bộ vòng đời phát triển phần mềm đồng thời bảo vệ các ứng dụng khỏi các lỗ hổng bảo mật trước, trong và sau sản xuất. Tôi tận dụng hơn 25 năm kinh nghiệm của mình trong việc phát triển và tiếp thị sản phẩm để dẫn dắt các nhóm của mình, những người chịu trách nhiệm về kỹ thuật, quản lý sản phẩm và thiết kế sản phẩm của tất cả các sản phẩm tại Contrast.

2 sự thật thú vị về tôi:
- Tôi có bằng đen cấp 2 môn Taekwondo.
- Tôi thích chơi những giai điệu rock cổ điển trên cây đàn guitar.

Hãy theo dõi tôi trên Cảm ơn, Mónica Freitas, rất vui được nói về cách tôi đến với Contrast! Tôi gia nhập khoảng 18 tháng trước sau khi làm việc tại các công ty lớn như Citrix, Oracle và Sun Microsystems. Tôi đã từng làm việc với vai trò quản lý và đóng góp cá nhân trong cả Kỹ thuật và Quản lý sản phẩm, quay trở lại những ngày của tôi với tư cách là thành viên ban đầu của nhóm Java vào cuối những năm 90. Vui lòng trả lời các câu hỏi về câu đố Java / Sun ban đầu nếu mọi người quan tâm. 🙂 Câu chuyện nhanh mặc dù về cách tôi đến với Contrast. Trong vai trò trước đây của mình, tôi đã rơi vào tình huống mà một nhóm hàng trăm kỹ sư đã hoàn toàn bị trật bánh bởi một nhóm bảo mật đang chạy một sản phẩm "quét mã" tồi. Nó tạo ra một khoản nợ kỹ thuật khổng lồ cho chúng tôi (mà chúng tôi buộc phải giải quyết), nhưng hầu như không có cải tiến nào trong tình hình bảo mật của chúng tôi. Nó làm trượt lịch trình và tạo ra sự thất vọng lớn. Tham gia Contrast, tôi nhận ra có một cách tốt hơn để làm điều đó! Chào Steve! Bạn có thể giải thích serverless là gì không? Cảm ơn, Zach Taylor! Serverless là một trong những thuật ngữ có ý nghĩa rất lớn đối với rất nhiều người, vì vậy chúng ta hãy chia nhỏ nó ra. Về bản chất, đó là một tập hợp các công nghệ được thiết kế để làm cho việc tính toán phía máy chủ hiệu quả hơn và đơn giản hơn. Một cách sử dụng của thuật ngữ này là về ý tưởng trừu tượng hóa khái niệm "Máy ảo" (ala VMware) và thay vì sử dụng các cấu trúc có thể mở rộng, trọng lượng nhẹ hơn như Docker Containers và Kubernetes. Tuy nhiên, tôi nghĩ rằng có một chuyển động thú vị hơn đang diễn ra bên trong Serverless ... Cuộc cách mạng lớn nhất trong 20 năm đối với kiến trúc ứng dụng là Chức năng như một Dịch vụ. Ví dụ phổ biến nhất về điều này là Amazon Web Services (AWS) Lambda - mặc dù các đám mây khác như Microsoft và Google đã thêm các cấu trúc tương tự. Giống như cách mà Java Servlet là một cải tiến lớn trong kiến trúc web so với "CGI" trước đó, các chức năng Serverless có thể nhanh hơn và rẻ hơn 100 lần so với kiến trúc truyền thống. Các chức năng này không phải lúc nào cũng thú vị, chúng "dựa trên sự kiện" hơn và chỉ chạy khi cần thiết. Bạn thấy những thứ này đang được sử dụng ở những nơi mà khả năng mở rộng lớn và chi phí thấp là rất quan trọng. Ứng dụng Internet of Things (IoT) nơi bạn có thể gửi dữ liệu từ hàng nghìn hoặc hàng triệu thiết bị trở lại dịch vụ thu thập dữ liệu. Đây là công cụ thực sự thú vị.

Điều đó rất thú vị cho các nhà phát triển! Và khi bạn đề cập đến IoT, có vẻ như nó mở ra cánh cửa cho rất nhiều trường hợp sử dụng khác nhau.

Bảo mật không máy chủ khác với bảo mật ứng dụng truyền thống như thế nào?

Câu hỏi tuyệt vời, Zach Taylor! Có rất nhiều khác biệt! Về mặt "cộng", bạn mất rất nhiều thứ mà bạn có thể "không" lo lắng. Bạn không cần phải lo lắng về việc có Hệ điều hành hoặc thậm chí là Máy chủ ứng dụng mà bạn cần vá. Tất cả những gì "biến mất" bên dưới bạn. Một số phiên bản vẫn tồn tại ở đâu đó, nhưng bạn không nhìn thấy hoặc quản lý chúng. Đó là một điểm cộng lớn từ góc độ bảo mật! Tuy nhiên, về mặt "thận trọng", mã của bạn cho ứng dụng của bạn sẽ trông THỰC SỰ khác. Trên thực tế, bạn nên giả định rằng các công cụ AppSec mã của bạn (như "máy quét mã") của bạn hoàn toàn không hoạt động. Tất cả các điểm vào và ra đều khác nhau nên luồng logic của bạn cũng khác. Bạn cần các công cụ AppSec hoàn toàn mới để đảm bảo bạn có thể phát hiện ra 10 lỗ hổng loại OWASP hàng đầu (tất cả vẫn còn tồn tại). Trên thực tế, OWASP có toàn bộ rất đáng để tham khảo. Vì vậy, bạn vẫn còn hai điều lớn cần lo lắng mà các công cụ AppSec của bạn cần trợ giúp: lỗ hổng trong mã Nguồn mở bạn mang theo và lỗ hổng trong mã tùy chỉnh bạn viết. Tuy nhiên, cũng có một mục mới cần lo lắng đó là quyền Quản lý Danh tính và Truy cập (IAM) của bạn trên mỗi chức năng. Đó là một phần quan trọng trong việc giữ an toàn cho mã của bạn khi nó chạy trên đám mây công cộng, nhưng việc làm bằng tay sẽ rất khó khăn. Tốt hơn hãy đảm bảo rằng bạn có một công cụ có thể tự động hóa điều đó cho bạn. Wow, đó là rất sâu sắc! Vì vậy, bất chấp sự cân bằng (ưu và nhược điểm của cả hai), về tổng thể, có vẻ như tự động hóa là một thành phần quan trọng trong việc lấp đầy những khoảng trống? Top 10 OWASP đó trông rất thú vị, tôi chắc chắn sẽ đi sâu hơn về vấn đề đó — cảm ơn bạn đã chia sẻ! Chào Steve! Nếu một tổ chức cân nhắc việc chuyển sang môi trường không máy chủ / cloud-native, thì mối đe dọa / nguy hiểm tức thời nhất là gì? Đội bảo vệ cần lưu ý điều gì để cải thiện khả năng bảo vệ?

Này, Victor de Avila, câu hỏi hay! Trong khi công nghệ không máy chủ loại bỏ nhiều trách nhiệm bảo mật đối với các công nghệ cơ bản, các nhà phát triển vẫn đang quan tâm đến việc đảm bảo các chức năng không máy chủ. Nếu mã được viết theo cách không an toàn, ứng dụng vẫn có thể dễ bị tấn công ở cấp ứng dụng truyền thống, như Cross-Site Scripting (XSS), Command / SQL Injection, Denial of Service (DoS), xác thực và ủy quyền bị hỏng, cấu hình sai bảo mật , và nhiều cái khác.

Các nhóm bảo mật không chỉ phải đối phó với các lỗ hổng và phơi nhiễm phổ biến (CVE) hoặc các rủi ro liên quan đến các thư viện mã nguồn mở, mà môi trường không máy chủ còn đưa ra các mối đe dọa do kiểm soát truy cập bị hỏng, đặc biệt khi các nhà phát triển cần thêm quyền để hỗ trợ các chức năng cần thiết. Trong tình huống này, nhà phát triển thường được nhóm bảo mật hướng dẫn chọn từ danh sách các quyền được xác định trước cung cấp nhiều quyền truy cập đặc quyền hơn mức cần thiết. Một quy trình tự động hóa tốt có thể là một cơ hội tuyệt vời cho một ứng dụng ít đặc quyền nhất - điều mà trước đây ở cấp độ đó là không thể. Tuy nhiên, việc tự động hóa quy trình này ở quy mô lớn, một cách chính xác và nhanh chóng là điều không dễ dàng.

Trong môi trường không có máy chủ, bề mặt tấn công cũng tăng lên do các cuộc tấn công không hoạt động phổ biến hơn và việc kiểm tra và giám sát khó khăn hơn so với các ứng dụng truyền thống. Do đó, các tổ chức cần tuân theo các nguyên tắc đặc quyền ít nhất và đảm bảo kiểm soát truy cập mạnh mẽ để giảm bề mặt tấn công và đảm bảo chỉ những cá nhân được ủy quyền mới có quyền truy cập.

Tương tự như vậy, các nhóm DevSecOps cũng nên lưu ý đến "sự lan rộng" trong các chức năng không máy chủ. Các chức năng có thể có nhiều phiên bản, ở các khu vực khác nhau và trên nhiều tài khoản, khiến nhóm quản lý và bảo mật khó hiểu được quy mô tổng thể của khoảng không quảng cáo không máy chủ ở cấp tổ chức. Để giải quyết vấn đề này, họ sẽ cần các biện pháp kiểm soát quản lý tài sản mạnh mẽ liên quan đến cả cơ sở hạ tầng đám mây và máy chủ.

Cuối cùng, các nhóm nên xem xét quyền thư viện của họ. Mặc dù nó không khác với bảo mật ứng dụng thông thường, nhưng các chức năng có xu hướng phụ thuộc rất nhiều. Ngoài ra, trong một số trường hợp, ngay cả khi mã có vẻ sạch, cơ sở hạ tầng (chẳng hạn như IaC) có thể giới thiệu nhiều thư viện hơn tại thời điểm triển khai, dẫn đến các lỗ hổng bên thứ ba bị bỏ sót. Các nhóm DevSecOps nên kích hoạt các quy trình bảo mật mạnh mẽ với một con mắt quan trọng đối với những cân nhắc cụ thể về máy chủ này. Xin chào, Steve Wilson! Tôi rất muốn biết về thời gian làm việc của bạn tại Oracle. Bạn đã làm gì ở đó?

Xin chào, Jack Boreham, cảm ơn bạn đã đặt câu hỏi! Tôi đã làm việc tại Oracle trong khoảng 3,5 năm từ 2010 đến 2013. Trong thời gian đó, tôi là "Phó Giám đốc Kỹ thuật cốt lõi" cho nhóm Quản lý Doanh nghiệp. Đây là bộ công cụ quản lý của Oracle cho toàn bộ danh mục đầu tư của họ (từ phần cứng đến hypervisor đến cơ sở dữ liệu, phần mềm trung gian và ứng dụng). Đó là một công việc mà tôi đã học được rất nhiều về cách làm việc trên quy mô lớn (nhóm của tôi có khoảng 500 người chia ra giữa Bắc Mỹ, Châu Âu (Pháp và Cộng hòa Séc) và Ấn Độ. Oracle có một nền văn hóa doanh nghiệp kỳ lạ, nhưng một nền văn hóa kỹ thuật rất kỷ luật (có bắt đầu với Oracle DB). Tôi đã học được rất nhiều về cách kiểm tra và chất lượng lái xe ở đó.

Tuy nhiên, để nói rõ hơn, tôi đã gia nhập Oracle khi họ mua lại Sun Microsystems. Tôi thực sự gia nhập Sun vào giữa những năm 90 với tư cách là một lập trình viên làm việc trên Bộ công cụ dành cho nhà phát triển Java, nơi tôi phải làm việc với tất cả những người thông minh như James Gosling (và nhiều người khác đã trở thành lập trình viên nổi tiếng và tạo ra những thứ tuyệt vời). Tôi bắt đầu làm việc trên Bộ công cụ GUI của Java và sau đó trở thành Kỹ sư hiệu suất toàn thời gian đầu tiên cho Java. Trên thực tế, tôi đã viết một về nó. Tôi sẽ cung cấp một liên kết chỉ cho vui, nhưng nó quá lỗi thời và tôi sẽ không đề nghị bất cứ ai đọc nó ngay bây giờ! 😉 Tôi chuyển sang quản lý và lãnh đạo nhóm NetBeans IDE (công việc yêu thích của tôi từ trước đến nay, BTW) và sau đó là nhóm quản lý Hệ thống và Ảo hóa của Sun. Hãy cho tôi biết nếu bạn có thêm câu hỏi về bất kỳ phần nào của vấn đề này. Rất nhiều câu chuyện thú vị về Sun / Oracle.

Steve Wilson, đó là một hành trình tuyệt vời!
Bạn đã phải đối mặt với những thách thức nào trong vai trò của mình trong Tương phản? Và ý bạn là gì về các giải pháp bảo mật tự phục vụ? Bạn có một bộ giải pháp bảo mật đã được thiết lập và bất kỳ công ty nào cũng có thể chọn những gì phù hợp nhất với nhu cầu của họ không? Doanh nghiệp có thể yêu cầu Contrast để có các giải pháp phù hợp không?

Mónica Freitas, cảm ơn bạn đã hỏi về Contrast! Contrast là một công ty chuyên về các công cụ giúp các nhà phát triển xây dựng các ứng dụng an toàn. Rất nhiều người nghĩ về những thứ như các công cụ bảo mật Mạng, Nhận dạng hoặc Điểm cuối khi họ coi bảo mật (và điều đó là quan trọng), nhưng tất cả chúng ta đang cố gắng bảo vệ điều gì khỏi tin tặc? Đó thực sự là về các ứng dụng của chúng tôi và dữ liệu chúng đang lưu trữ cho chúng tôi. Đó là lý do tại sao bảo mật ứng dụng rất quan trọng và đó là những công cụ mà Contrast xây dựng. Chúng tôi có cái được gọi là Nền tảng mã an toàn. Nó bao gồm nhiều công nghệ để trợ giúp các nhà phát triển và đội bảo mật. Điều này bao gồm quét mã nguồn (SAST), thiết bị đo có thể kiểm tra ứng dụng của bạn từ "từ trong ra ngoài") IAST, bảo vệ thời gian chạy (RASP) thực sự có thể vô hiệu hóa những kẻ tấn công đang cố gắng khai thác lỗ hổng zero-day. Các ví dụ gần đây là những thứ như Log4J và Spring4Shell. Và cuối cùng, gần đây chúng tôi đã giới thiệu các công cụ bảo mật đầu tiên trên thế giới cho mã Serverless gốc đám mây. Chúng tôi rất vui khi được trao đổi với mọi người về các tùy chọn tốt nhất về cách tạo chương trình DevSecOps cho phép họ duy trì tốc độ phát triển nhưng cũng đảm bảo mã của họ được bảo mật. Bạn có thể liên hệ để biết thêm chi tiết . Mónica Freitas, về chủ đề bảo mật "tự phục vụ" ... Các giải pháp bảo mật tự phục vụ đề cập đến khả năng các nhà phát triển tự sử dụng các công cụ Contrasts và sử dụng chúng theo cách họ thấy phù hợp nhất. Điều này có nghĩa là các nhà phát triển và nhóm DevOps chỉ có thể nhận được các công cụ họ cần để hoàn thành công việc và có thể tìm và sửa các lỗ hổng với đào tạo bảo mật tối thiểu (hoặc giám sát liên tục từ một nhóm kỹ thuật bảo mật chuyên dụng). Đối với việc yêu cầu Contrast cho các giải pháp phù hợp, hoàn toàn. Nhóm của chúng tôi có thể hướng dẫn các nhóm về những gì sẽ hoạt động tốt nhất dựa trên mục tiêu của họ cũng như nhu cầu dài hạn và ngắn hạn. Steve Wilson, những vấn đề bảo mật phổ biến nhất mà bạn đã gặp là gì và các công ty có thể thực hiện những bước nào để giải quyết chúng? Mónica Freitas, cảm ơn vì câu hỏi về các vấn đề bảo mật phổ biến nhất. Tôi sẽ tránh xa những thứ như lừa đảo và mật khẩu xấu (vì đó là cơ sở rõ ràng và dễ hiểu). Thay vào đó, tôi sẽ tập trung vào các vấn đề khi tạo các ứng dụng an toàn. Có hai điều chính bạn cần xem xét: bảo mật mã do bạn viết và bảo mật mã bạn sử dụng mà người khác đã viết (thường là mã nguồn mở). Với đoạn mã bạn viết, có một số lượng lớn các loại lỗ hổng được phân loại. Một trong những cách phổ biến nhất (và nghiêm trọng nhất) được gọi là tấn công "tiêm". Điều này có nghĩa là một thực thể bên ngoài (hacker!) Có thể đưa dữ liệu vào một số phần của hệ thống của bạn theo cách mà bạn không lường trước hoặc không có ý định. Đây có thể là những thứ giống như "SQL Injection Attack" trong đó hacker có thể đưa một phần ngôn ngữ truy vấn cơ sở dữ liệu vào cơ sở dữ liệu của bạn và thực thi nó từ xa. Điều này thực sự phổ biến và đã là một vấn đề hàng đầu trong 20 năm. Một cách khác thường được cho là ít nghiêm trọng hơn là "Log File Injection", nơi một tin tặc có thể thả trực tiếp dữ liệu bị nhiễm độc vào một tệp nhật ký của ứng dụng của bạn. Nghe có vẻ như nó không quá tệ, nhưng đây là trọng tâm của sự cố bảo mật Log4J gần đây đã ảnh hưởng đến rất nhiều công ty vào tháng 12 / tháng 1. Đối với mã nguồn mở, chúng tôi biết rằng phần lớn mã trong các ứng dụng kinh doanh hiện đại thậm chí không được viết bởi các nhà phát triển của công ty. Nó là mã nguồn mở. Nó mở cửa cho tất cả các loại tấn công và trong khi mã nguồn mở cung cấp một nền tảng vững chắc cho mã an toàn bằng cách có nhiều con mắt theo dõi mã, nhiều người trong số đó hiện là tin tặc (từ sinh viên đến tin tặc quốc gia). Một số thư viện này (như Struts, Log4J, Spring) phổ biến đến mức chúng được nhúng vào hàng triệu ứng dụng trên khắp thế giới. Một vài năm trước, cơ quan xếp hạng tín dụng có tên Equifax đã sử dụng phiên bản Struts dễ bị tấn công và làm mất dữ liệu tài chính cá nhân của hàng trăm triệu người Mỹ. Kết quả là họ đã bị phạt hơn $ 400.000.000 đô la. Đây là điều nghiêm trọng. Cách tốt nhất để xử lý cả hai vấn đề này là hiện đại hóa các hoạt động dành cho nhà phát triển của bạn để bao gồm các công cụ tự động giúp bạn phát hiện và khắc phục những loại vấn đề này. Nền tảng mã bảo mật của Contrast hoạt động với Java, JavaScript .NET, Go, Ruby, Python, Scala & Kotlin, vì vậy nếu bạn đang sử dụng bất kỳ công nghệ phổ biến nào trong số này, chúng tôi rất sẵn lòng giúp bạn hiện đại hóa các công cụ của mình và xây dựng một chương trình để tự động hóa tất cả điều này. Này Steve Wilson! Tôi tò mò, SBOM là gì? Chúng có thể tác động đến hệ thống an ninh không? Sara Pinto, cảm ơn bạn đã hỏi về SBOM. Một lĩnh vực thú vị và mang tính thời sự ngay bây giờ! Đây thực sự là một phần của chủ đề lớn hơn có tên Bảo mật chuỗi cung ứng phần mềm. Như đã lưu ý trong một số câu hỏi khác trên chủ đề này, phần lớn mã trong các ứng dụng hiện đại không được viết bởi các nhà phát triển của chính công ty. Nó từ bên thứ ba (thường là mã nguồn mở). Cách đây ít lâu, một nhà cung cấp phần mềm có tên Solar Winds đã bị tấn công. Điều đó thật tệ đối với gió mặt trời, nhưng điều tồi tệ hơn là mã Solar Winds được xây dựng đã được nhúng vào môi trường trung tâm dữ liệu và đám mây của nhiều công ty khác và thậm chí cả chính phủ. Biết được điều này, những tin tặc đã tấn công SolarWinds không chỉ ăn cắp từ SolarWinds mà chúng còn tận dụng cơ hội để đặt các cửa sau vào phần mềm của SolarWind mà sau đó sẽ được nhiều công ty khác nhúng vào. Cuộc khám phá rất lớn và nó dẫn đến ý tưởng rằng bạn phải theo dõi mã của riêng mình, nhưng cũng là mã bạn nhận được từ nơi khác. Toàn bộ quy trình phải được bảo mật từ đầu đến cuối và đó được gọi là Bảo mật chuỗi cung ứng phần mềm. SBOMs là viết tắt của phần mềm hóa đơn nguyên vật liệu. SBOM là danh sách tất cả các thành phần mã nguồn mở và bên thứ ba có trong cơ sở mã ngoài tất cả các giấy phép chi phối các thành phần đó. Hãy coi đó là nhãn dinh dưỡng trên mặt hộp thực phẩm. Nó giúp người tiêu dùng biết những gì trong thực phẩm để họ có thể sử dụng nó để đảm bảo thực phẩm an toàn và lành mạnh cho họ. SBOM có thể tạo ra sự minh bạch hơn trên thị trường phần mềm và cũng cho phép các nhà phát triển hành động nhanh chóng nếu một lỗ hổng bảo mật đã được xác định. gần đây tuyên bố rằng SBOM phải được yêu cầu và NTIA đã phát hành " " cho những điều cần phải có của SBOM, và nhiều điểm trong số này chỉ được nhấn mạnh thêm trong và thông tin kèm theo . Hơn nữa, Gartner dự đoán rằng đến năm 2025, 60% các tổ chức xây dựng hoặc mua sắm phần mềm cơ sở hạ tầng quan trọng sẽ bắt buộc và tiêu chuẩn hóa các SBOM trong thực hành kỹ thuật phần mềm của họ. Mặc dù đây là những bước đầu tiên tuyệt vời để bảo mật các ứng dụng hiện đại — bao gồm cả máy chủ — các nhà phát triển và nhóm bảo mật vẫn đang nỗ lực để giữ an toàn cho ứng dụng của họ và trách nhiệm đó thuộc về các nhóm DevSecOps. Steve Wilson, khi Web3 phát triển, bạn có cân nhắc khả năng tạo các tùy chọn bảo mật cho web3 không? Mónica Freitas, cảm ơn vì câu hỏi rất nhiều về bảo mật Web3. Đây là một chủ đề FASCINATING và là một chủ đề khá rộng. Tôi sẽ cố gắng thêm quan điểm của tôi. Đầu tiên, chúng ta phải xác định Web3. Trong nền văn hóa đại chúng, ý tưởng về Web3 được thống trị bằng việc kinh doanh các tác phẩm nghệ thuật kỹ thuật số kỳ lạ. Có những cuộc thảo luận liên tục về các âm mưu Ponzi và gian lận. Nhưng tôi nghĩ các khái niệm về Web3 thật hấp dẫn. Khi bạn loại bỏ tất cả, Web3 là một nhóm nỗ lực táo bạo (và tôi chắc chắn rằng nhiều người sẽ thất bại) để xây dựng lại phần lớn Internet từ đầu. Tại sao chúng ta cần làm như vậy? Chà, nó thực sự là về bảo mật và sự tin cậy! Internet và world-wide web nằm trên nó được xây dựng bởi các học giả dành cho học thuật. Họ có nghĩa là để mở thông tin, tiến bộ khoa học và công nghệ và thúc đẩy trao đổi ý tưởng. Theo nghĩa đó, internet / web là nỗ lực thành công nhất trong lịch sử loài người.

Tuy nhiên, vì bản chất của nó, nó thiếu một khái niệm chính - niềm tin! Làm sao tôi biết bạn là ai? Làm thế nào để tôi biết những gì bạn sở hữu? Làm thế nào để tôi biết bạn được hưởng những gì? Không có cái nào trong số đó được tích hợp vào internet ngay từ đầu. Mọi thứ nằm trên lớp đó đều mong manh và được kiểm soát tập trung. Làm thế nào để tôi biết những gì bạn sở hữu? Tôi hỏi ngân hàng / công ty phát hành thẻ tín dụng của bạn. Làm thế nào để tôi biết bạn là ai? Chà, đó là một vấn đề gần như hoàn toàn chưa được giải quyết trên internet cho đến ngày nay!

Web3 có xu hướng bắt đầu với các khái niệm được tiên phong bởi Bitcoin / tiền điện tử - với cốt lõi là Blockchain. Khoảng bốn năm trước, tôi thấy con gái tuổi teen của mình và bạn bè của nó đang sử dụng dịch vụ VPN miễn phí để vượt qua tường lửa của trường trung học để chúng có thể xem Netflix ở trường. Thay vì tức giận, tôi thấy đây là một cách tuyệt vời để mở cuộc trò chuyện với cô ấy về bảo mật và mật mã (NERD DAD ALERT!). Bằng cách nào đó, chúng tôi bắt tay vào cuộc phiêu lưu tuyệt vời khai thác Ethereum và tìm hiểu về Blockchain. Bạn có thể đọc về một số cuộc phiêu lưu của chúng tôi .

Điều này khiến cá nhân tôi thực sự đi sâu vào cách thức hoạt động của Blockchain. Theo một số cách, đó là một kỳ quan khoa học máy tính, và theo một số cách, đó là một cơn ác mộng kỹ thuật, nhưng nó đã đi tiên phong trong một loạt các khái niệm mới về cách bạn phân phối lòng tin mà không có cơ quan trung ương. Đây là cốt lõi của web3! Làm cách nào để biết bạn là ai và bạn sở hữu gì (trong một bối cảnh nhất định) mà không cần tổ chức bên thứ ba ở giữa cho tôi biết? Nếu bạn quan tâm đến việc đọc những suy nghĩ của tôi về mặt tốt và xấu của blockchain, bạn có thể xem . Nó đã được vài năm tuổi, nhưng các khái niệm cốt lõi ở đây đang phát triển đủ chậm để tất cả đều liên quan phần lớn đến cuộc thảo luận. Vì vậy, bây giờ chúng ta hãy xuống đồng thau! Tôi sẽ nói gì với ai đó đang tìm cách đi sâu vào bảo mật web3? Đầu tiên, có những trường hợp lỗi bảo mật cao trong các blockchain nhỏ hơn. Sự tin tưởng trong chuỗi khối thường dựa trên biểu quyết đồng thuận và nếu bạn không có khối lượng quan trọng, thì ai đó có thể sở hữu hơn 50% số phiếu bầu và bạn đang gặp rắc rối. Tuy nhiên, tôi không nghĩ đây là chủ đề quan trọng nhất đối với các nhà phát triển nhìn vào Web3 ngày nay. Khi tôi xem xét các sự cố bảo mật lớn xung quanh Web3 / NFT / Crypto trong những năm gần đây, chúng không liên quan đến blockchain cốt lõi. Chúng ở xung quanh các phần Web2 của mã / cơ sở hạ tầng của một công ty vẫn gắn kết thế giới lại với nhau. Trò chơi Web3, trong một cuộc chơi rất dài hạn (nghĩ về hàng thập kỷ), là thay thế nền tảng của Internet bằng những thứ bao gồm lòng tin như một thành phần cốt lõi. Điều đó có thể xảy ra, và điều đó thật đáng khen ngợi, nhưng còn lâu mới xảy ra. Ngày nay, chúng ta có những thứ như IPv4 / 6, SSL, HTML, JavaScript, REST, AppServers, thư viện mã nguồn mở và cơ sở dữ liệu SQL kết nối thế giới với nhau (với các công nghệ blockchain / web3). Nếu bạn đang điều hành một sàn giao dịch NFT (hoặc một cái gì đó tương tự) thì tôi sẽ dành nhiều (hoặc nhiều hơn) thời gian của mình để lo lắng về phần Web2 trong thế giới của tôi, là chất kết dính giữa tôi và khách hàng / đối tác của tôi. Nó dễ bị ảnh hưởng bởi tất cả các khái niệm bảo mật ứng dụng tương tự mà chúng ta đã nói trước đây ở đây. Bạn cần một chương trình và nền tảng DevSecOps TUYỆT VỜI. Và hầu hết nó sẽ trông giống như một bộ xử lý thẻ tín dụng hoặc một ngân hàng lớn. Sự tương phản có thể giúp ích ở đây. Nếu bạn có thể làm cho "keo" Web2 của mình ngang bằng với một ngân hàng lớn, thì bạn có thể dành thời gian lo lắng về cách tạo sự khác biệt trong thế giới Web3. Đó là thời gian thú vị. Tôi không thể chờ đợi để xem điều này phát triển như thế nào. Hãy cho tôi biết nếu bạn muốn nói thêm về chủ đề này. Tôi rất thích trò chuyện! Steve Wilson, tôi là người mới đối với tất cả các Tiêu chuẩn bảo mật phần mềm này. Bạn có thể nói rõ hơn về chúng? Tôi nên biết gì về điều này? Sara Pinto, cảm ơn vì câu hỏi về Tiêu chuẩn bảo mật phần mềm. Ồ! Bạn vừa đánh vào một chủ đề thực sự lớn và quan trọng. Nhìn chung, có hai loại tiêu chuẩn: Hợp đồng / thương mại và Theo luật định. Tiêu chuẩn thương mại là những thứ sẽ giúp bạn kinh doanh. Việc tuân thủ một trong các tiêu chuẩn này có thể được viết thành hợp đồng. Ví dụ: khách hàng của bạn có thể yêu cầu bạn tuân thủ một tiêu chuẩn gọi là SOC2 và thường xuyên được đánh giá để chứng minh điều đó. Mặt khác, để bán Dịch vụ Điện toán Đám mây cho Chính phủ Hoa Kỳ, bạn phải tuân thủ một bộ tiêu chuẩn được gọi là FedRAMP (đó là "theo luật" nên nó được coi là một yêu cầu theo luật định). Cả hai ví dụ này đều thú vị và quan trọng nếu bạn đang điều hành một công ty phần mềm / SaaS. Tuy nhiên, đối với các nhà phát triển cá nhân, chúng thực sự rất trừu tượng. Ví dụ, các tiêu chuẩn này bao gồm rất nhiều mục không chỉ là "phần mềm". Một ví dụ điển hình là, bạn có đủ kiểm tra lý lịch và đào tạo cơ bản về bảo mật cho tất cả nhân viên của mình không?

Đối với các nhà phát triển phần mềm, có những tiêu chuẩn chi tiết hơn giúp đi sâu hơn vào các chi tiết mà bạn có thể muốn lo lắng. Dưới đây là một phần danh sách những điều thú vị để bắt đầu khám phá trong hành trình của bạn! Lưu ý rằng một số yêu cầu là kỹ thuật và một số yêu cầu là quy trình mà bạn sử dụng để xây dựng phần mềm.

Lệnh điều hành an ninh mạng 14028

PCI SSF (PA-DSS được thay thế)

OWASP

NIST

CISA

OMB

Quyền riêng tư (bảo mật là điều kiện tiên quyết đối với quyền riêng tư

Khác

Điều này đã được rất vui tất cả mọi người. Cảm ơn đã tham gia! Tôi sẽ xem kênh này trong suốt thời gian còn lại của ngày, nhưng nếu đây là sự kết thúc của chủ đề này, tôi sẽ để lại cho bạn một chút gì đó mà tôi đang làm việc. Hy vọng la bạn se thich no! Cảm ơn bạn đã tham gia với chúng tôi Steve Wilson và vì những câu trả lời chu đáo của bạn. Chúng tôi rất thích có bạn ở đây!