Những quan sát từ Ngày Công nghiệp Nguồn mở của NSA năm nay

Observations f-rom this year's NSA Open Source Industry Day

Posted 23 Sep 2013 by Mark Troester

Theo: http://opensource.com/government/13/9/nsa-open-source

Bài được đưa lên Internet ngày: 23/09/2013

Image by opensource.com

Lời người dịch: Ngày Công nghiệp Nguồn Mở của NSA ở Maryland năm 2013 đương nhiên mọi điều đều quay xung quanh các vấn đề của phần mềm nguồn mở. Có những điều không gây ngạc nhiên và có những điều gây ngạc nhiên cho tác giả của bài viết này, nhất là khi đề cập tới các vấn đề về phát triển, quản lý và điều hành các dự án nguồn mở trong khu vực chính phủ. Nếu bạn làm việc trong khu vực chính phủ và lại đang có ý nghĩ sẽ tham gia sử dụng và phát triển nguồn mở trong chính phủ, thì bạn rất nên đọc bài viết này và tự suy ngẫm về những quan sát đó của tác giả bài viết.

Tôi đã dự Ngày Công nghiệp Nguồn Mở của NSA ở Maryland năm nay và nghĩ tôi muốn tóm tắt những gì đã và đã không làm tôi ngạc nhiên. Chúng ta sẽ thấy liệu những quan sát đó có chứng minh còn là tranh cãi hay hữu ích! Quan trọng hơn chúng ta sẽ thấy liệu các tổ chức có thể có hiệu quả để quản lý, điều hành và đảm bảo an ninh cho các ứng dụng của họ hay không, biết rằng thực tế của nguồn mở, các thực tiễn phát triển đàn hồi và sự phát triển dựa vào các thành phần.

Những gì không gây ngạc nhiên?

• Các tổ chức đang tìm kiếm một sự hiểu biết về nguồn mở. Họ đang tìm kiếm ai đó hoặc điều gì đó để nắm được trách nhiệm. Họ muốn “một cái cổ họng duy nhất để bóp”. Họ có điều kiện để nghĩ cách này dựa vào sự hỗ trợ theo lịch sử mà họ nhận được từ các nhà cung cấp phần mềm độc lập mà cấp giấy phép phần mềm sở hữu độc quyền. Và bây giờ, họ quay sang các nhà cung cấp như Red Hat vì sự hỗ trợ phần mềm hạ tầng nguồn mở. Nhưng mô hình đó không làm việc cho hàng trăm hoặc hàng ngàn thành phần nguồn mở mà có nguồn từ các dự án hoặc các kho khác nhau. Một mô hình mới là cần thiết.

• Nguồn mở = Linux, MySQL, JBoss. Khi mọi người nghĩ về nguồn mở, họ nghĩ tới các phần m ềm hạ tầng lớn - họ không nghĩ về các thành phần nguồn mở được sử dụng để xây dựng các ứng dụng. Nhiều người không nhận thức được hoặc lên kế hoạch cho thực tế là 80% của một ứng dụng được cấu thành từ các thành phần nguồn mở. Cho tới khi họ chấp nhận thực tế này, sẽ là khó khăn cho họ để triển khai các qui trình cần thiết để đảm bảo an ninh cho các ứng dụng dựa vào các thành phần.

• Sự không đồng ý về những đóng góp nguồn mở. Trong khi mọi người đồng ý rằng sự làm việc của các hệ thống bí mật hoặc riêng tư sẽ không được chia sẻ, thì đã có sự không thống nhất về công việc không nhạy cảm. Và đã có những câu hỏi về giá trị của việc chia sẻ công việc. Điều này đã dẫn tới một cuộc thảo luận về làm thế nào kiểm soát được các vấn đề có lieenn quan tới việc tận dụng các phiên bản nguồn mở mới. Đây là một bài thú vị về những hiểu lầm về nguồn mở trong chính phủ.

• Sự không đồng ý về việc liệu sự truy cập tới mã có trao cho những kẻ đột nhập lợi thế hay không. Nhiều cuộc thảo luận về các làm thế nào “nhiều con mắt làm cho mã an toàn hơn”, và hội thoại thú vị về việc liệu sự truy cập tới mã có trao cho những kẻ đột nhập một lợi thế hay không. Một số nghĩ thế, nhưng số khác đã viện lý rằng điều đó không phải là vấn đề gì vì các tin tặc có thể đơn giản làm kỹ thuật nghịch đảo những gì họ cần từ nhị phân.

• Các tổ chức không thể theo kịp với các phiên bản phần mềm mới nhất. Nhiều tham luận viên và những người tham dự đã than vãn về khả năng của họ để giữ được phần mềm của họ là hiện hành - thậm chí với phần mềm hạ tầng lớn. Khi nghĩ về điều này trong ngữ cảnh của các thành phần, vấn đề này thậm chí còn tệ hơn.

Những gì từng gây ngạc nhiên?

• Mọi người vẫn tin vào sự ảo tưởng các kho vàng. Có lẽ điều này sẽ không là ngạc nhiên, nhưng phản ứng giật đầu gối đối với nhiều thách thức nguồn mở như “chúng ta chỉ cần đảm bảo rằng các lập trình viên sử dụng phiên bản hiện hành”. Hoặc, “chúng ta nên chắc chắn rằng chỉ phiên bản hiện hành nhất là sẵn sàng cho tải về từ Internet”. Dù là tốt để có một kho cung cấp một vài sự kiểm soát (chúng tôi không đưa rra Người quản lý Kho Liên hệ theo cách đó!), chúng ta biết rằng không có điều như là một kho vàng. Có nhiều vấn đề với tiếp cận này: các lập trình viên sẽ bỏ qua nó; sẽ là quá hạn chế cho những nỗ lực phát triển ban đầu, … Chắc chắn một kho là một sự khởi đầu, nhưng bạn cần chỉ dẫn và điều hành thông qua vòng đời của phần mềm, bao gồm cả sự hỗ trợ cho môi trường sản xuất.

• Mọi người vẫn còn nghĩa về một qui trình phê chuẩn là cách để quản lý PMNM. Một tổ chức đã nói về cách mà họ có một ban lãnh đạo rà soát lại nguồn mở. Được nói từ đại diện của một CISO - đây là cách mà nó diễn ra... cảnh báo, thật buồn!

Chủ sở hữu của thành phần PMNM (người mà muốn sử dụng nó) - họ viết một rà soát lại tỉ mỉ, bao gồm cả giá trị nghiệp vụ … Nó đi tới pháp lý và chúng ta chắn chắn chúng ta không có một vấn đề pháp lý nào, hoặc một vấn đề hợp đồng nào. Một khi pháp lý được làm xong, chúng ta đi tới ban lãnh đạo rà soát lại - và phụ thuộc vào sự đúng lúc của dự án - họ ưu tiên nó với các khoản khác trong hàng đợi. Nó sau đó đi qua một sự rà soát lại về an ninh - nó cũng cấp chức năng nào, nó sẽ động chạm tới cái gì nữa? Chúng ta phải hiểu gốc rễ - tôi phải biết doanh nghiệp của tôi và mạng của tôi trông thế nào ngày nay. Chúng tôi quan tâm trng các yêu cầu về tính riêng tư, các yêu cầu giao dịch. Liệu chúng tôi làm điều đó có an ninh hay không? Liệu có các giao thức đang được sử dụng hay không? Một khi điều này được thực hiện, chúng tôi sẽ đi sâu hơn vào mã bằng việc sử dụng các công cụ được tự động hóa. Cuối của sự rà soát lại toàn phần đó - pháp lý, kỹ thuật, an ninh - chúng tôi đưa ra một quyết định quản lý rủi ro. Chúng tôi có muốn nó trong doanh nghiệp của chúng tôi không? Điều đó là sự cho và lấy với lập trình viên - chúng tôi thích điều này, chúng tôi cần điều này được thay đổi...

Tôi sẽ không tranh luận rằng đó là những cân nhắc không quan trọng. Tôi sẽ chỉ nói rằng tiếp cận này không làm việc được dựa vào lượng, sự khác biệt, tính phức tạp và nhịp độ phát hành của các thành phần - thậm chí nếu tiến trình công việc được tự động hóa. Hãy nghĩ về tiếp cận này trong một môi trường phát triển đàn hồi mà nó tận dụng sự chạy nước rút ngắn! Điều này giải thích vì sao các lập trình viên phản ứng đối với các nỗ lực về chính sách. Các lập trình viên bị ép phải bỏ qua qui tình để thực hiện các thời hạn chót của họ. Hoặc họ phải dựa vào các thành phần mà đã từng được phê chuẩn, thậm chí nếu chúng chưa là thành phần tốt nhất cho công việc.

• Mọi người đánh đồng an ninh ứng dụng với DAST / SAST. Trong khi các công nghệ đó đóng một vai trò nhất định, thì một số tổ chức ép khớp các công nghệ đó vào việc quản lý sử dụng nguồn mở. Nhưng có bao nhiêu tổ chức thực sự muốn tham gia vào với mã thành phần của nguồn mở? Họ hướng sang các thành phần cho chức năng “nằm ngoài cái hộp”. Họ hướng tới các thành phần sao cho họ không phải tự họ xây dựng nó. Họ không muốn có tham gia vào trong mã - họ thường thậm chí không có mã luôn. Và vì sao chờ đợi để quét mã nguồn cho các thành phần cho tới khi chúng được sử dụng trong quá trình phát triển khi thông tin được biết rồi về các thành phần đó nhỉ? Thông tin mà có thể được sử dụng để lựa chọn các thành phần tối ưu ngay từ đầu của qui trình phát triển. Trong khi DAST / SAST có chỗ của chúng, thì sự phát triển dựa vào thành phần không thể được quản lý theo cách y hệt như chúng ta quản lý mã tùy biến mà may các thành phần lại cùng nhau.

Những hiện thực hóa chính

Bạn có đồng ý với các quan sát thấy đó không? Bạn có đồng ý rằng chúng ta cần phải hành động không? Dựa vào những hội thoại diễn ra ở hội nghị, các chủ đề chung đó chỉ ra sự tiến bộ chắc chắn trong mặt trận nguồn mở:

• Quản lý chuỗi cung ứng. Biết rằng qui trình phát triển ứng dụng được hỗ trợ bằng các thành phần có nguồn bên ngoài, bằng việc sử dụng các nguyên tắc chuỗi cung ứng để quản lý vòng đời phát triển là một chủ đề chung. Có một sự hiện thực hóa mà toàn bộ vòng đời của phần mềm cần phải được hỗ trợ, và các tổ chức có trách nhiệm về ứng dụng đó bất kể cái gì cấu thành nên ứng dụng đó. Mọi người hiểu cách mà các thành phần có thể được sử dụng để dẫn dắt tới tính hiệu quả của các lập trình viên, cũng như an ninh, việc cấp phép và rủi ro về chất lượng có thể được quản lý.

• Tự động hóa là chìa khóa. Thậm chí dù tôi đã hoàn toàn không nghe DevOps lần nào, đã có khá nhiều thảo luận xung quanh việc tự động hóa qui trình phát triển và phân phối. Trong khi sự tự động hóa này điển hình được tập trung vào chuỗi công cụ phân phối ứng dụng (IDE, các công cụ xây dựng, CI, CD, …), thì nó có thể dẫn tới những thảo luận xung quanh sự tự động hóa chính sách. Các chính sách được tự động hóa có thể đưa ra chỉ dẫn và ép tuân thủ trực tiếp trong các công cụ được sử dụng để phát triển và phân phối các ứng dụng phần mềm.

• Trao cho các lập trình viên những gì họ muốn. Có một sự hiện thực hóa đang gia tăng rằng an ninh cần phải cung cấp cho các lập trình viên những gì họ muốn. CISO hiểu rằng các lập trình viên sẽ bỏ qua những kiểm soát của họ nếu chúng cản trở qui trình phát triển. Họ nhận thức được rầng họ phải vượt qua gánh nặng “tích cực rởm” và “tiêu cực rởm” mà là kết quả của nhiều công cụ an ninh ứng dụng. Và họ đang bắt đầu nhận thức được rằng việc cung cấp thông tin cho các lập trình viên trong ngữ cảnh của họ đòi hỏi sự tích hợp trong các công cụ mà họ sử dụng. Ví dụ, hãy nhìn vào cách mà nền tảng CLM của Sonatype tích hợp các dữ liệu an ninh nguồn mở và tự động hóa các chính sách một cách trực tiếp trong IDE nơi mà các lập trình viên làm việc hàng ngày.

• Sửa đổi an ninh để làm việc với cách mà các ứng dụng ngày nay sẽ được phát triển. Các nỗ lực về an ninh và chất lượng phải gắn với các tiếp cận phát triển hiện đại - và điều đó không chỉ là việc dàn xếp sử dụng nguồn mở. Đã có khá nhiều thảo luận về sự phát triển đàn hồi, và cách mà các nỗ lực an ninh và chất lượng phải phù hợp trong cấu trúc đó. Giữa những điều khác, nó có nghĩa là các nỗ lực về chính sách và sự tuân thủ phải phù hợp trong các vòng đời phát triển đàn hồi ngắn.

• Các tổ chức phải nắm lấy trách nhiệm về mã và các thành phần mà được cấp nguồn từ bên ngoài. Có một sự hiện thực hóa đang gia tăng rằng các lập trình viên sử dụng nguồn mở phải quản lý nó có hiệu quả. Nhưng trách nhiệm này sẽ không rơi vào chỉ các lập trình viên; toàn bộ tổ chức cần phải hỗ trợ cho nỗ lực đó. Và các tổ chức phải làm thế theo một cách thức mà hỗ trợ cho quy trình phát triển đó một cách tự nhiên, không bằng sự ép buộc phù hợp với các tiếp cận xưa cũ. Câu trả lời không thể là chúng ta sẽ không sử dụng nguồn mở - có quá nhiều giá trị có thể bị mất. Đây là một video từ Goldman mà trình bày giá trị mà nguồn mở cung cấp.

• Kho chứa (Silos) (tất cả các dạng) cần phải bị loại bỏ. Trong khi DevOps dẫn đường bằng việc chia thành các kho Phát triển và các lựa chọn IT, thì không chỉ sự trà xát của tổ chức làm cản trợ tính đàn hồi. Trong bài phát biểu chính của mình, Tiến sĩ Patrick Dowd, CTO và Kiến trúc sư trưởng của NSA, đã nói về cách mà họ đang đi khỏi một kiến trúc dựa vào cac vùng đất ở giữa vì các “kho chứa – silos” đã làm khó khăn để phân tích dữ liệu mà đã đi qua vùng đất ở giữa đó. Thay vào đó, họ đã chuyển tới một kiến trúc mà tận dụng được các công nghệ nguồn mở để phân phối tiện ích, dữ liệu và hỗ trợ kho lưu trữ dựa vào đám mây. Các tổ chức nhận thức được họ có khả năng hơn để đáp ứng được cho các mục tiêu đàn hồi và tốc độ nếu họ dỡ bỏ các kho chứa về tổ chức, công nghệ và kiến trúc.

Nếu bạn từng dự sự kiện đó, hoặc nếu bạn làm việc trong khu vực chính phủ, bạn có đồng ý với các quan sát đó không? Nếu bạn làm việc trong nền công nghiệp khác, nó có lẽ giúp suy nghĩ về cách mà quan điểm này có liên quan tới nền công nghiệp của bạn.

I attended the NSA Open Source Industry Day in Maryland this year and thought I'd summarize what did and didn't surprise me. We'll see if these observations prove controversial or helpful! More importantly we'll see if organizations can effectively manage, govern, and secure their applications given the reality of open source, agile development practices, and component-based development.

What wasn't surprising?

• Organizations are looking for an open source savior. They are looking for someone or something to hold accountable. They want "a single throat to choke." They are conditioned to think this way based on the historical support they receive f-rom ISVs that license proprietary software. And now, they turn to vendors like Red Hat for open source infrastructure software support. But that model doesn't work for the hundreds or thousands of open source components that are sourced f-rom different projects or forges. A new model is needed.

• Open source = Linux, MySQL, JBoss. When people think open source, they think large infrastructure software—they don't think of the open source components that are used to build applications. Many are not aware or planning for the fact that 80% of an application is comprised of open source components. Until they accept this reality, it will be difficult for them to implement the processes necessary to secure component-based applications.

• Disagreement about open source contributions. While people agreed that classified or secret system work shouldn't be shared, there was disagreement about non-sensitive work. And there were questions about the value of sharing this work. This led to a discussion about how custom change leads to forked internal versions that are difficult to maintain and the change control issues associated with leveraging new open source versions. Here is an interesting article about open source in government misconceptions.

• Disagreement about whether access to code gave hackers an advantage. Lots of discussion about how "many eyes make for safer code," and interesting conversation about whether access to code gave hackers an advantage. Some thought so, but others argued that it doesn't matter because hackers can simply reverse engineer what they need f-rom the binary.

• Organizations can't keep up with the latest versions of software. Many panelists and attendees lamented their ability to keep their software current—even with large infrastructure software. When thinking about this in the context of components, the problem is even more daunting.

What was surprising?

• People still buy into the golden repository fallacy. Perhaps this shouldn't be surprising, but the knee-jerk reaction to many open source challenges was "we just need to ensure that developers use the current version." Or, "we should make sure that only the most current version is available for download f-rom the Internet." Although it's great to have a repository to provide some control (we do provide the Nexus Repository Manager by the way!), we know that there is no such thing as a golden repository. There are many problems with this approach: developers will bypass it; it will be too restrictive for initial development efforts, etc. Sure a repository is a start, but you need guidance and governance throughout the software lifecycle, including support for the production environment.

• People still think an approval process is the way to manage OSS. One organization spoke about how they have an open source review board. Told f-rom the perspective of a CISO—here is how it goes... warning, it's painful!

The owner of the OSS component (the person that wants to use it)—they write up an in-depth review, including the business value... It goes to legal and we make sure we don't have a legacy issue, or a contract issue. Once legal is done, we go to review board—and depending on the timing of the project—they prioritize it with other items in the queue. It then goes through a security review—what functionality does it provide, what else will it touch? We have to understand the baseline—I have to know my enterprise and what my network looks like today. We factor in privacy requirements, transactional requirements. Do we do these securely? Are there protocols being used? Once that is done, we go deeper into the code using automated tools. At the end of the full review—legal, technical, security—we make a risk management decision. Do we want it in our enterprise? It's give and take with the developer—we like this, we need this changed...

I'm not arguing that these aren't important considerations. I'm just saying that this approach doesn't work based on the volume, variety, complexity, and release cadence of components—even if the workflow is automated. Think about this approach in an agile development environment that leverages short sprints! This is why developers resist policy efforts. Developers are forced to bypass the process to make their deadlines. Or they have to rely on components that have already been approved, even if they aren't the best component for the job.

• People equate app security to DAST / SAST. While these technologies certainly play a role, some organizations force fit these technologies into managing open source usage. But how many organizations really want to get involved with open source component code? They turn to components for "out of the box" functionality. They turn to components so they don't have build it themselves. They don't want to be involved in the code—they often don't even have the code. And why wait to scan source code for components until they are used in the development process when information is already known about those components? Information that can be used to se-lect optimal components at the beginning of the development process. While DAST/SAST have their place, component-based development can't be managed the same way that we manage the custom code that stitches components together.

Key realizations

Do you agree with these observations? Do you agree that we need to act? Based on the conversations took place at the conference, these commonthemes indicate solid progress on the open source front:

• Supply chain management. Given that the application development process is supported by components sourced externally, using supply chain principles to manage the development lifecycle was a common theme. There is a realization that the entire software lifecycle needs to be supported, and that organizations are responsible for the application regardless of what constitutes the application. People understand how components can be used to drive developer efficiency, as long as security, licensing and quality risk can be managed.

• Automation is key. Even though I didn't hear DevOps uttered once, there was plenty of discussion around automating the development and delivery process. While this automation is typically focused on the application delivery toolchain (IDE, build tools, CI, CD, etc.), it can lead to conversations around policy automation. Automated policies can provide guidance and enforcement directly in the tools that are used to develop and delivery software applications.

• Give developers what they want. There is a growing realization that security needs to provide developers what they want. The CISO understands that developers will bypass their controls if they hinder the development process. They realize that they have to overcome the "false positive" and "false negative" burden that is the result of many application security tools. And they are starting to realize that providing information to developers in their context requires integration into the tools that they use. Look, for example, at how Sonatype's CLM platform integrates open source security data and automate the policies directly in the IDE whe-re developers work every day.

• Modify security to work with how today's apps are developed. Security and quality efforts must be aligned with modern development approaches—and that's not just accommodating the use of open source. There were plenty of conversations about agile development, and how security and quality efforts have to fit within that construct. Among other things, it means that policy and compliance efforts must fit within short agile development cycles.

• Organizations must take responsibility for code and components that are externally sourced. There is a growing realization that developers using open source must manage it effectively. But this responsibility should not fall on the developer alone; the entire organization needs to support the effort. And organizations must do so in a way that supports the development process naturally, not by force fitting legacy approaches. The answer can't be we just won't use open source—there is too much value that would be lost. Here is a video f-rom Goldman that represents the value that open source provides.

• Silos (of all kinds) need to be removed. While DevOps leads the way by breaking down Development and IT Ops silos, it's not just organization friction that stifles agility. In the keynote, Dr. Patrick Dowd, NSA CTO and Chief Architect, talked about how they are moving away f-rom an enclave-based architecture because the "silos" made it difficult to analyze data that crossed enclaves. Instead, they have moved to an architecture that leverages open source technologies to deliver cloud-based utility, data, and storage support. Organizations realize they are more likely to meet agility and speed goals if they dismantle organization, technology and architecture silos.

If you attended the event, or if you work in the government sector, do you agree with these observations? If you work in another industry, it might help to think about how this perspective relates to your industry.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com