运用Scrum实现敏捷信息安全

需积分: 10 69 浏览量更新于2024-07-21 收藏 1017KB PDF 举报

"Agile Information Security: Using Scrum 1511804246" 本书《Agile Information Security: Using Scrum》由James Fitzer撰写，旨在引导读者如何将敏捷方法论融入信息安全流程，特别是在使用Scrum框架的情况下。书中通过作者参与的美国高调边境安全项目——北方边境整合示范项目（Northern Border Integration Demonstration）的经验教训，提供了关于改进信息安全程序效率的建议和案例。书中的核心思想是简化安全流程，适应变化，回归信息安全管理的本质——保护组织资产并支持企业运营。书中的章节涵盖了以下几个关键知识点： 1. **敏捷哲学**：首先介绍敏捷开发的基本理念，强调快速响应变化、迭代开发和持续改进的重要性。敏捷方法鼓励团队与利益相关者紧密合作，确保产品满足实际需求。 2. **Scrum在信息安全中的应用**：Scrum是一种敏捷开发框架，书中详细解释了如何将其应用于信息安全领域，包括角色定义（如产品负责人、Scrum Master和开发团队）、Sprint周期、每日站会和回顾会议等实践。 3. **安全风险评估**：讨论如何在敏捷环境中进行有效的风险评估，以识别和管理潜在威胁，同时保持项目的敏捷性。 4. **可接受的风险**：探讨如何确定和接受风险，平衡安全性和业务连续性，以确保组织能够适应不断变化的威胁环境。 5. **合规与敏捷**：在敏捷环境中处理合规性的挑战，说明如何在快速迭代的过程中满足法规要求。 6. **实施控制、预防、监控和响应**：介绍如何在敏捷项目中设计和执行有效的安全控制措施，以及如何建立监控和响应机制，以应对安全事件。 7. **最终思考**：作者总结了在整个过程中学到的关键教训，提供进一步的反思和建议，帮助读者在实践中持续改进。 8. **参考文献**：列出相关资料，供读者深入研究。 9. **关于作者**：简要介绍作者James Fitzer的背景和联系方式。这本书对于那些寻求在信息安全领域实现敏捷转型的项目经理、安全专业人员和IT领导者来说，是一份宝贵的资源。它提供了一种简化和适应性更强的安全管理方法，以应对现代企业面临的复杂性和不确定性。

The Northern Border Integration Demonstration

The Northern Border Integration Demonstration, or NBID, was a system built and

installed in the Operational Integration Center, or OIC, at Selfridge Air National Guard

base near Chesterfield, Michigan. The facility was built to enhance collaboration

between various federal, state, and local agencies including the Border Patrol,

Michigan State Police, U.S. Coast Guard, Customs and Border Protection (CBP), the

Royal Canadian Mounted Police, and other agencies throughout the area. The goal was

to increase situational awareness along a critical border region encompassing around

35 miles of territory including the St. Clair River. The NBID’s Collaboration Network

(CN) combined organic CBP capabilities, government and private video surveillance

systems, commercial feeds (weather, traffic, geodata) with custom software to present a

customizable common operational picture for analysts and leadership.

NBID’s development team came from the department of the Navy, and was based

at the Naval Surface Warfare Center in Dahlgren, Virginia. The goal was to build the

system and capability using a combination of commercial-off-the-shelf and proprietary

systems, and the NSWC team was selected due to their established expertise in system

integration. The team used agile processes heavily to enhance their ability to quickly

respond to new feature requests and emerging customer needs, as is fitting with a

demonstration of capability.

Given the development team’s split allegiances between the Department of

Homeland Security and the Department of Defense, the system engineers (whom I led)

experienced great challenges maintaining compliance with various security standards

and accreditation, while still being able to support the mission of the system. Over the

years, we discovered ways to overcome these obstacles, and this book is borne from

those efforts. Throughout the course of this book, you’ll find frequent referrals to NBID

to illustrate key concepts, reinforce team-building ideas, and provide examples of how

the techniques outlined within can help your organization become more agile.

Before delving into these techniques, however, we will examine the principles and

philosophy behind agile development, and how these principles can help us better

accomplish the mission, and more quickly react to change.

Peltier, T., Peltier, J., & Blackley, J. (2005). Information Security Fundamentals. Boca Raton: Auerbach

Publications.

Beck, Kent, et al. (2001). The Agile Manifesto. Retrieved from http://www.agilemanifesto.org

VersionOne. (2013). 8th Annual State of Agile Development Survey. Retrieved from

http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf

CHAPTER 2

The Agile Philosophy

The first time I ever mentioned the idea of applying a more agile philosophy to security

and information assurance to another person, he asked me if I needed help finding a

place to buy patchouli oil and incense. He told me, “Security isn’t something you adopt

a philosophy for. There isn’t any real leeway. You get standards from someone else,

you meet them.”

We tend to forget that philosophy is simply the underlying ideas or theories in a

given discipline. It refers to any set of beliefs or values applicable to whatever field

you’re involved in, whether that’s law, the nature of reality, or security engineering. Our

philosophy on something hinges not just on the standards of the discipline, but also our

goals, our value system, and our personal point of view.

And yet, I’m willing to bet that not a lot of people give too much thought to their

personal philosophy on information security. For the average user, security is merely an

obstacle to their work, and something to impede their progress, versus a piece of the

organization that supports their work. From an engineering or development perspective,

security is often viewed as another chore to accomplish so we can “get back to work”

installing the newest whiz-bang piece of equipment or producing more software. If

either of those is true in your enterprise, then there are improvements to be made in your

company’s security philosophy, ranging from simple tweaks to a complete overhaul of

the program. Unfortunately, it’s common for people to think that their organization

simply can’t do things a different way.

In a lot of organizations, it’s quite tempting to believe this. After all, every last one

of us has worked in an organization where we heard things like “We could do it

better… but this is how it’s done here.” Usually, a statement like this reflects either

process, tradition, or simply laziness; not wanting to expend the effort to find another

way. We’ll discuss resistance to change further along in this chapter, and some

strategies to overcome it. For now, let’s focus on how adopting an agile philosophy can

promote positive organizational change, within the security team and beyond.

The agile philosophy is reflected by a set of principles enumerated by the writers

of the Manifesto

. Each of these provides guidance and direction for those working to

build agility into their teams and projects, and are presented here in the context of the

agile information security program.

Agile Principles

Customer Satisfaction through Early, Continuous Delivery

No matter what particular flavor of agile development you subscribe to, one of the key

concepts is customer satisfaction through delivering useful software continuously and

early. Through the lens of an information security program, our “customer” is the

organization we support; our “products” are the controls we implement, the required

artifacts we deliver for compliance and risk, and the training and policy changes

necessary to better accomplish our goals. The point of this principle is: get a useful

product into the customer’s hands early. The customer receives an early product and has

a chance to voice feedback and concerns that can be rolled into a later release. Once a

task is finished, it’s onto the next piece of work, and the product should be released the

moment it is operationally useful and functional. The customer gets to see continuous

progress on the deliverables, whatever they may be, and provide feedback early.

Meanwhile, your team can adjust to that feedback quickly. Everyone is satisfied, and

development continues.

In the case of controls, once testing has identified that the risk associated with the

control is mitigated, it’s time to move that control into effect. Further refinement and the

ability to tune the product shouldn’t delay its initial implementation: a security

appliance you’re testing on a non-production network isn’t stopping any threats. It is up

to the individual team to determine at what point operational utility is high enough to

justify implementation in production, but the premise behind this principle is “earlier

rather than later.”

But what about the documents and artifacts we produce? In fact, we already know

that agile in general values working products over documentation, so why not skip

boring security risk assessments and regulatory requirements in favor of the newest,

latest security gadgetry?

Remember, an information security program isn’t just about implementing

technology. It’s also about providing decision makers the information they need to make

good decisions about their technology. It also means ensuring our users are informed,

well trained, and that the effectiveness of our programs are periodically evaluated.

So, in an agile security program, our “working product” includes documentation

that furthers the goals of our department or organization. And in the spirit of this agile

principle, that documentation should be delivered as soon as it is operationally useful. If

a security risk assessment, the results of a policy audit, or a new training module can

guide decisions and set more work in motion, then it’s time to deliver them. Early,

continuous delivery of these decision-making and support products help our

organization accomplish its mission.

Embrace Changing Requirements

The very phrase “changing requirements” strikes fear into the hearts of engineers

everywhere. There’s always trepidation involved with late-breaking changes to a

product, particularly one that has been produced as the result of a great deal of

manpower and effort. It may be tempting, especially once a great deal of infrastructure

and documentation has been delivered, to avoid change or to discourage others from

introducing change. This is particularly apparent in the information security world,

where a small change in infrastructure could have a devastating effect on the accuracy

and validity of risk assessments, accreditation documents, and security policy. Resist

the temptation to avoid change, and learn instead to thrive on it.

Remember, agile processes were developed for the express purpose of responding

well to change. We are delivering products at short intervals, so each sprint (a concept

which will be introduced later) is not a monumental undertaking. Embracing change is

simply about communication: listening to our organization’s needs and responding to

them. Anticipating those needs, and being ready for them. The security team that can

react to rapid change in requirements becomes accustomed to shifting focus and

refocusing resources. This is the team we want when there’s a major incident, data

spillage, or other high-level problem. Recall that information security exists to support

the enterprise. What better way to do this than quickly and efficiently react to their

changing needs?

Frequent Delivery

This agile principle lends itself particularly well to our business, given the fast-paced

nature of emerging threats. Ideally, we should be delivering new features, patches,

closing exploits, and updating relevant documentation every few weeks. In the case of a

critical zero-day vulnerability, an out-of-band update immediately upon discovery is not

outside the realm of possibility. Frequent deliveries also reduce the complexity of any

individual delivery, simplifying troubleshooting, change control, and diagnosis of any

regressions introduced, for example as a result of an operating system patch, network

device firmware, or ACL change.

剩余95页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

运用Scrum实现敏捷信息安全

Addison.Wesley.Agile.Game.Development.with.Scrum.May.2010.rar

java.lang.ClassNotFoundException: com.cbcs.agile.common.security.grant.DisposableFreeLoginCodeAuthen

agile 9.3.1.2

agile 和scrum的关系

js实现在“000/087/004/agile8700427.dwg”在最后一个/前面添加/buf 变成000/087/004/buf/agile8700427.dwg

You+are+handed+over+a+project+of+a+bank+for+testing.+Using+agile+scrum

哪里有学习敏捷卫星的基本知识的教程

想要学习敏捷开发我可以参考哪些资料和链接？

java获取agileplm的受影响物件更新表事件删除一行的操作

最新资源