The general characteristics of any Agile methodology are:

1. Prioritizing feedback. Agile teams rely heavily on the feedback they get on the products they deliver.
2. Speedy delivery of small batches. Agile teams prefer to present their product in small iterative chunks instead of a single large one.
3. Team ownership. Most of the decisions are made at the team level, making the Agile team responsible and accountable for the work they complete.
4. Familiarity with Repetition. Agile methodologies encourage the team to repeat the process as much as possible to be familiar with it and, eventually to automate it if possible.
5. Inspect and Adapt. Iteration is an integral part of any Agile methodology can be seen in the development of a product as well as in the methods and processes that the teams follow. It encourages the team to adapt to new changes and challenges in an enterprise by facilitating a continuous learning culture and openness.

There are several agile methods and approaches that software development teams pick and choose for the type of products they build. Scrum, Extreme Programming (XP), Kanban, and Lean Development are some of the popular ones. Most organizations choose Scrum and Kanban as the base for its Agile methodology.

A security team should always look for ways to make the Agile team’s job easier by helping them to develop and deliver software securely. They will be an enabler for an Agile team if they follow the recommendations listed below.

1. The security team should be part of the agile team and be engaged as much as possible in the delivery of their product. They should be Agile to keep up with the Agile teams by thinking and acting quickly and iteratively. They should respond fast and keep learning and improving along with the development team.
2. A Cybersecurity Architect (CSA) should be engaged in the review of a user story before it becomes part of the product backlog of the agile team. They are encouraged to participate in the product planning sessions.
3. An Information Risk Manager (IRM) aligned to the line of business (LoB) should be engaged at the beginning and towards the end of each sprint.
4. An Application Security Champion (ASC) should be part of a sprint team guiding the developers and helping them find solutions to fix security defects in the code.
5. The security checks and tests must be automated so that they can be efficiently and transparently plugged into developer workflows and build pipelines
6. The security team should develop a Reference Architecture as a tool that enables agile teams to deliver products that are compliant with the firm’s policies and standards. The Reference Architecture would help the agile teams move fast and continuously learn and improve.

Introduction

A Software Development Life Cycle (SDLC) is a framework that defines the process used by organizations to build an application from its inception to its decommission. (Mougoue, 2016) Historically almost all organization has been using the waterfall SDLC methodology to deliver products to its customers. However, recently, enterprises are moving towards a new method called Agile that helps to deliver products to the market rapidly. This paper discusses Agile methodology and how an information security team can enable the Agile teams at various touchpoints in the method.
The paper discusses:

• Agile SDLC methodology and its characteristics.
• Scrum and Kanban methods in Agile.
• Integration of security in Agile methods.
• Security team engagements in Agile methodology
• The need for a security reference architecture in Agile methodology
• Selected recommendations for the information security team to enable Agile teams.

Agile SDLC

Agile Software Development Lifecycle (SDLC) model is a combination of iterative and incremental process models with a focus on process adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break a product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks and involves cross-functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration, the customer and critical stakeholders are presented with a working product. (Tutorial Point, 2017)

According to the Agile Manifesto (Beck, et al., 2001), there are four primary values to be considered when considering Agile Methodology:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The signatories of the manifesto also state that “while there is value in the items on the right, we value the items on the left more.” (Beck, et al., 2001) They believe both parts of each value statement are necessary. However, they appreciate the first part more than the second. Behind the value statements are 12 principles (Beck, et al., Principles behind the Agile Manifesto, 2001) which form the backbone of most agile methodologies.

Characteristics of Agile Methods

Though there are many Agile methods, most teams that start with a well-known method end up with a hybrid one that combines two or more well-known methods.

Most of the Agile team have the following characteristics:

Prioritizing Feedback. Agile teams rely heavily on the feedback they get on the products they deliver. They look for it as soon as possible to help increase the speed at which the software is in a demonstrable state. Feedbacks also contributes to reducing barriers to communication that prevent real decision-makers from seeing the results of their decisions.

Feedback loops, where part of the output of each Agile iteration is used as input for another iteration, is also a valuable tool that the Agile team relies on. It encourages retrospectives on each iteration or continuous improvement capabilities, ensuring the process itself is adaptive and delivering value.

Practices such as continuous integration, rapid deployment, and production testing facilities are mechanisms that could speed up feedback. Such mechanisms that minimize the pathways to production and increases the chances of getting feedback as soon as possible are the hallmark of an agile methodology.

Speedy Delivery Of Small Batches. Agile teams prefer to deliver their product in small iterative chunks instead of a single large one. The delivery could be into a pre-production or staging environment rather than directly into production, allowing them to test the delivered workload with other workloads of the product. Small workloads also enable them to concentrate on a few features at a time while also working on the feedback received on a previously completed workload.

The effectiveness of an Agile team is measured in terms of velocity, which is the number of features delivered to production or a staging area. As such, an Agile team must invest time in automating their systems as much as possible to improve the team’s velocity.

Iterative Development. Because feedbacks and feedback loops are critical for Agile teams, all Agile methods are iterative. Iterative development facilitates reducing the impact of rework while giving active feedback to the decision-makers regarding the cost of the rework. For example, a Scrum team needs to estimate and prioritize any rework of a completed workload against the workloads in an existing scrum backlog.

Team Ownership. Most of the decisions are made at the team level, making the Agile team responsible and accountable for the work they complete. They are also free to find ways to improve and automate their processes and practices. It is a common practice within an Agile team to rely on an Agile coach to help them with such improvements.

Familiarity with Repetition. Agile is a new SDLC methodology and could unfamiliar to many who are still in the traditional waterfall methodology. Delivering a product almost every two or three weeks is entirely new to such teams and could be painful or awkward. To avoid such situations, Agile methodologies encourage the team to repeat the process as much as possible to be familiar with it and eventually, if possible, to automate it.

Inspect and Adapt. Iteration is an integral part of any Agile methodology can be seen in the development of a product as well as in the methods and processes that the teams follow. The iterative process requires monitoring the effectiveness of the iteration and inspecting the value delivered in each process and product. Value stream mapping, time logs, velocity, and retrospectives are some of the tools to examine and adjust each process. Though it is a change in culture from the traditional waterfall methodology, it encourages the team to adapt to new changes and challenges in an enterprise because it facilitates continuous learning culture and openness.

Agile Methodologies

There are several agile methods and approaches that software development teams pick and choose for the type of products they build. Scrum, Extreme Programming (XP), Kanban, and Lean Development are some of the popular ones. The firm where the author works have chosen Scrum and Kanban as the base for its Agile methodology.

Scrum

Scrum is by far the most popular agile methodology and is conceptually simple, and can integrate into many existing project and program management frameworks. It is prevalent among managers and senior executives as they feel they can understand more easily what a team is doing, and when they will be finished with a scrum. (Brunton-Spall, Smith, Bird, & Bell, 2017)

Each scrum project is delivered by a small multidisciplinary product development team that shares a requirements backlog. The size of the group is generally between five and 11 people, and the team usually contains developers, testers, and designers, a product manager or Product Owner, and someone playing the Scrum Master role. The Scrum Master is a team member who leads and coaches the team for a particular scrum.

Sprints and Backlogs. The product backlog or Scrum backlog is a collection of stories. Each story is a very high-level requirement for the product. The product manager continuously prioritizes work in the backlog and verifies that stories are still relevant and usable. This prioritization and verification process is called “backlog grooming.”

Each scrum team works in increments called sprints. Though traditionally a sprint is one-month long, the collective Scrum teams can decide how long each sprint should. It varies from team to team. For some, it is three weeks, and for others, it is three months. At the end of each sprint, the team stops its work, assesses the work that they have completed and how well they did it, and then resets for the next sprint.

At the beginning of a sprint, each scrum team, which includes the product manager, would look through the product backlog to prioritize the stories before selecting each story for delivery. For each chosen story, the team would provide an estimate to complete it. The stories are then prioritized before adding them to the backlog.

The estimates for each story are provided as real units of time or in relative but abstract sizing. Examples of real units of time could be two working days or 16 working hours, while examples of abstract sizing could be in t-shirt sizes as small, medium, and large. Using abstract sizing allows the team to say a story is bigger than the other, helping them to provide a much looser estimate for the Scrum Master to monitor the team’s ability to deliver on the stories.

While reviewing and prioritizing the stories for a sprint backlog, the Scrum team may decide to take out some stories and may select to add some extra ones depending on their estimate to complete each story. Sometimes there could be large stories that may need to be split into smaller ones or need to be swapped for other smaller ones instead. A finalized sprint backlog is an agreement from the sprint to complete them on time.

Each sprint agreement is reached when the product manager has completed the story prioritization for the sprint backlog, and the Scrum team accepts the prioritized sprint backlog. No stories are added to a sprint backlog while the sprint is being worked on by the Scrum team. Any new stories that occur during a sprint need to be added to the broader product backlog for prioritization and cannot be added to an active sprint. This prevents the product manager from changing the backlog in the middle of a sprint allowing the Scrum team to deliver reliably from sprint to sprint. The product manager has the flexibility to update the product backlog whenever needed and before a sprint begins. However, there is no flexibility when a sprint starts. Any feedback coming out of a sprint must be added to a product backlog and then prioritized to a new sprint.

Team cohesion is necessary for a Scrum team. For that, the team needs to be co-located if possible or should be able to collaborate virtually using tools such as group instant messaging, discussion forums, and conference calls enabling them to discuss or engage during the day. Security team members working with an Agile team should be able to participate in such collaborations. It is essential to remove barriers and encourage sharing security knowledge as much as possible to build the trust relationship between the security team member and the rest of the Scrum team.

Stand-Up Meetings. Each day of the Scrum team starts with a stand up with a short meeting called a Stand-Up. That’s where everyone in the group addresses a whiteboard or other record for the sprint stories and discusses the day’s work. For a team that is collocated, a physical whiteboard is more than enough to track their stories. The stories are represented as individual cards that move through swimlanes of state change. However, a team that is geographically dispersed should use an electronic system such as that of IssueTracker in JIRA from Atlassian to present and track stories on a virtual card wall.

The swimlanes should be organized in such a way that there should be swimlanes for Ready-to-play, In-Development, and Done. They could add extra swimlanes such as Design and Testing that represent the state of the story as needed.

All members of the Scrum team must attend the stand-up. While most of the participants are observers in the meeting, there could be a few team members who are responsible for delivering a story at the meeting. The security team member, who is a contributor to the team, participates as an observer.

Each presenter in the team answers the following questions in the stand-up:

1. What did you do yesterday?
2. What are you going to do today?
3. What is blocking you?

While the presenters are answering these questions, the observers are expected to be silent and not interrupt the presenter. The presenter who completed a story moves the story card to the next swimlanes and gets credit for delivering the stories as agreed. Anything that prevents the agreed delivery of a story is called a blocker.

The primary day-to-day job of a Scrum Master is to remove blockers from the team. The Scrum Master could block a story because it is ready to play or to be worked on. It is usually because of a dependency on a third-party resource or delivery from a resource outside the team. The team relies on the Scrum Master to remove blockers in the sprint.

Scrum Feedback Loops. As mentioned earlier, feedbacks are very critical for a Scrum team. At the end of each Scrum, the team gets together to spend time holding a retrospection on the completed sprint and find out what they can do better in the next sprint. Such feedback loops are a valuable source of information for security teams. The security team can learn directly from the development teams about a project and provide continuous support during the product development instead of only participating in a particular gate or review sessions.

For a product that has a significant number of security stories in the backlog, the security team member should be an active participant in the sprint instead of being an observer or just a participant in the feedback look sessions.

Kanban

Unlike Scrum, which is a methodology for building a software product, a Kanban is a method for running a high functioning team. Edward Deming developed Kanban while he worked at Toyota and Toyota Production System. He wanted to improve efficiency on the manufacturing floor, where a workstation processed from an in-queue and placed the results into an out-queue. He found that sometimes the results waited for long to be picked up from the out-queue by the next workstation and proposed a solution to avoid that. Deming proposed a system based on a just-in approach to each station, enabling each station to request (or pull) work from the previous station when it was ready for the next piece of work. (Brunton-Spall, Smith, Bird, & Bell, 2017)

The Kanban system helps to prioritize how fast a piece of work or workload would travel from the beginning of a system to the end, and the number of touchpoints it should go through. The speed of the workload is called a “flow” or the “cycle time.”

There are many touchpoints in an Information Technology (IT) environment through which a concept should go through as a workload before it gets materialized in production. Some of the touchpoints have queues where the workload has to wait for its turn to be worked on. An example is a change control board to review and approve changes to production systems. A workload may have to wait until the next change control board meeting for it to get reviewed and approved regardless of whether the workload was completed a week or a month back. Kanban systems help to solve such issues based on three essential practices – (1) Kanban Board, (2) Constant Feedback, and (3) Continuous Improvement.

Kanban Board. The Kanban Board makes the flow of workload visible. Each station in a Kanban Board has a column for in-queue workloads, in-process workloads, and out-queue workloads. These stations could be Business Concept, High-Level Design, Security Architecture Review, Detailed Level Design, Development, Quality Assurance (QA), and Deployment in a software development environment. It helps to quickly visualize the flow of workload and determine where the workloads are clustered and the bottlenecks in the system.

According to the Kanban method, a predetermined capacity of a station strictly limits the amount of workload a station can work at a time. If the capacity of a station is to work on only five workloads at a time, then the station cannot take a new workload until an existing workload is complete. The method also allows a station to pull more workload from another station if it has the capacity for a new workload.

Constant Feedback. A workload cannot move any faster than the slowest station in the system, and any occurrence of trying to push a workload to move quicker than that station would create waste or delays elsewhere in the system. By providing a tool that shows the status of all workloads to everyone in the team, Kanban is providing constant feedback on their flow and the team’s capabilities. It encourages Kanban teams to rely on each other to give feedback helping the product sponsors and stakeholders to see the current state of the systems and how long it would take a new workload to complete. The team can prioritize the workloads appropriately based on such constant feedback.

Continuous Improvement. Kanban encourages everyone in the line of production at each station to identify opportunities for improvement to speed up the process flow. Since it is easy to find the bottleneck in a Kanban process, each improvement should give an immediate boost to the throughput of the entire system. That doesn’t mean there could be a continuous change in estimated time for delivery for a well-defined mature process with a predetermined service level agreements (SLA) at each station. Such processes would not see any noticeable changes enabling the product managers to prioritize their backlog based on customer needs.

As mentioned earlier, Kanban is more about team and activity management than an SDLC process. It is most suitable for teams that look after multiple products, and where the incoming work is not predictable. Such teams include IT support teams, operational teams, and security architecture teams where the kind of workloads that come could vary in nature.

In Kanban, smaller workloads tend to move faster with increased throughput making it an ideal method for DevOps teams. Security Architecture teams could leverage Kanban by breaking down large workloads into smaller chunks to be processed.

DevOps

While Agile teams are measured on their “velocity,” which is the capability to deliver working software as much as possible, the development and operations (DevOps) teams are valued and rewarded based on system stability. As such, developers tend to think of short term goal of delivering their products as soon as possible and may cut corners. They may not think about the operational aspects of the products. However, the operations team is focused on the long term stability of the environment where the products would reside. Cutting corners could destabilize the environment and is at odds with the goals of DevOps team.

To remediate the conflicting priorities situation, the Agile team may have to maintain and operate their services themselves on the infrastructure provided by the DevOps team. If anything goes wrong in their services, the Agile team takes some responsibility for the failure. The DevOps team would be primarily seen as enablers for the Agile team.

The DevOps team could be divided into three high-level categories:

1. Infrastructure teams that buy and manages infrastructure
2. Tooling teams that build automated tooling for self-provisioning and management of said infrastructure
3. Support teams that respond to incidents

DevOps team is responsible for standing up services such as logging, monitoring, alerting, and patching with an Application Program Interface (API) that the Agile team can use for the products they deliver. It would be up to the Agile team to use the API the right way for their services. The increasing shift towards tooling and automation in DevOps creates significant challenges for security. While the DevOps is engaged more into tooling and automation scripts than before, the security team who were previously focused on the infrastructure side has to now think about code and software design vulnerabilities in the tooling and automation scripts.

Agile and Security

Historically, the security practices and processes were built around the traditional waterfall methodology. The requirements are defined upfront, instead of for small teams who work quickly and iteratively. However, the requirements could change every few weeks with very minimal to no documentation in Agile. The Agile team creates the design and risk management decisions just in time during each iteration. The traditional manual testing and compliance checking cannot possibly keep up with the velocity of the Agile team.

Like the DevOps, the Security team needs to evolve into an Agile enabler by finding solutions to minimize any barriers in the delivery path of a workload helping the Agile team to realize their ideas. The security team can no longer reduce risk by minimizing change. Change is inevitable in an Agile environment, and the Security team needs to adapt to it. Otherwise, the Security team will be ignored and bypassed.

To have a smooth functioning of an Agile methodology, the Agile team needs to understand and adopt security practices. They need to take more responsibility for the security of their systems, similar to how they take ownership of the operations of their services. The product owners need to understand and prioritize security and compliance requirements while giving ample time for the Agile team to adopt security practices.

A security professional should be enablers for the Agile team by managing security risks in incremental terms in an environment that keeps on changing with faster iterative processes.

The idea behind having sequential phases such as design or requirement reviews, architecture reviews, code reviews, and security testing in the traditional waterfall model is to catch security defects early on the SDLC. Though the Agile practitioners agree to this concept, they believe the focus should be on reducing the cost of fixing defects by making changes safer and easier instead of trying to catch all defects early on to fix them.

Because each Agile iteration by itself is prioritized and then worked on either sequentially or in parallel, the defects could be detected early on in each sprint, but not all at once. Each sprint would have its own code reviews and security testing to detect defects. The detected defects would be fed back to the backlog to be prioritized and fixed by the Agile team in another sprint. That doesn’t mean all security decisions should be made at the sprint level.

Some security decisions should be made before the sprint iterations start. Determining the first, second, and third layer of protection for a product should be made after performing a threat model in the design or requirements phase for the product backlog. So is the decision to pick the right platform for the product. Such decisions cannot wait for a sprint to start.

Security Team

An understanding of the various groups in the security team is helpful before discussing how a security team can engage with an Agile team. There are three types of groups in the security team that could be leveraged by an Agile Team:

Cybersecurity Architects (CSA). These are a highly-experienced group of trusted advisors on cybersecurity. Each CSA is specialized in domains such as infrastructure, platform, web applications, cloud, mobile, and IoT. The CSAs perform threat models to determine the three layers of protection required for a product. Some CSAs are individually aligned to a line of business (LoB) so that they are up to speed on some of the emerging technologies in the LoB.

Information Risk Managers (IRM). These are security risk managers who have a fair understanding of the technology with a strong risk management background. Since each IRM is aligned to an LoB, they understand the risk appetite of the business and can provide informed advice to the business on whether to accept a risk or not.

Application Security Champions (ASC). These are software engineers trained in application security. They are trained to review reports on static code scans and dynamic scans and are capable of advising the Agile teams on how to remediate the findings in the report.

Security Team Engagement in Agile Methodology

Security Engagement in Sprint

There are many touchpoints in a sprint or iteration where the security team needs to be engaged.

Daily Stand-Up. As mentioned earlier, the daily stand-up is where the current state of stories are reviewed. Since the IRM group is closer to the LoB, it is the IRM who should be listening to any issues raised that may affect security and privacy. The IRM should monitor any stories that have security importance until completion.

Coding. During the coding of a story, it would be worthwhile to have someone with a strong security background in application security available for the team to understand the reports from the static scan and dynamic scan reports. An ASC is the best resource for the team to have at this level. They can advise the team on strategies to remediate any finding in the code or application. Each sprint should have its own ASC.

Beginning of a Sprint. At the start of a sprint, during the kick-off or planning meeting, most teams walk through all of the potential stories for the iteration together. The IRM should participate in the meeting, along with the ASC to ensure security requirements are understood and applicable to each story. IRM should make sure that the team owns and understand the security implications of each story.

End of a Sprint. Towards the end of a sprint, the IRM should be in the reviews and retrospective meetings to help understand what the team has done and any challenges that they faced. The IRM may engage a CSA if necessary.

Communications. As a member of the Agile team, the ASC needs to be in constant communication with other team members to lower any barriers to interacting with the security team. ASC should be the primary liaison for the Agile team from the security team. The ASC needs to be available to provide quick and informal guidance and answers to questions through instant messenger or chat platforms, email, and wherever possible in person so that the security team is not seen as a blocker.

Tools. The best way to assure that a product is secure for productions is to perform an exhaustive set of checks. Tools like Gauntlt, BDD-Security, Snyk, InSpec, Brakeman, ZAP, OSQuery, TruffleHog, Dependency-Check, and Error Prone helps to automate such tests that were traditionally manual. Though they don’t negate the need for manual testing, most of the tests could be reliably automated and repeated with these tools. The security team should own these tools, while the Agile team should own the implementation of the tools in their pipeline. The security team is responsible for determining the appropriate tools to be used in each phase, and the Agile team should be responsible for configuring them correctly.

Security Engagement Before a Sprint

Most of the Agile teams have a product design team working in advance of the development team, working on design problems, prototypes, architectural discussions. The output of this team feeds directly into the product backlog, ensuring that the development team is primed with stories ready for the forthcoming iteration.

Security Architecture Review. A CSA should be part of this team to address secure service design, trust modeling, and secure architecture patterns for the product. Each story that goes into the product backlog should be reviewed and approved by a CSA. The CSA needs to ensure that the service the team designed enables security through the user experience. Examples of such review should include analysis of how or whether to obfuscate user details when displayed, how changes to the information are gathered, and what identification requirements are needed for specific actions. Threat modeling should be leveraged to perform such reviews. Sometimes a CSA may need to become the solution architect for a story that has security significance.

Tools. To provide security-related guidance and patterns, the CSA should leverage tools such as a wiki for documentation. Having such documentation helps for future reference and other teams as well for reference.

Security Engagement After a Sprint

When a sprint has delivered a product and is ready for production, the security team should:

1. Assure that the developed product is secure.
2. Ensure that the product would be built and deployed securely every time.

Repeatable Automated Security Checks. Any security check that would be performed before a product goes into production should be automatable, reliable, repeatable, and understandable for an Agile team to adopt them. As much as possible, the tools used for a dynamic scan should be automated and be available for repeated use. The IRM should have a way to know what features have been released in the last iteration and ensure that those new features are added to the logging, fraud detection, analysis, and other security systems.

Risk Management. Any high-risk issue found before production should be monitored closely. It won’t hurt to accept a risk temporarily if the likelihood of the risk happening before a control can be put in place in a few iterations time is very low. The IRM needs to monitor the issue until it is mitigated.

Tools. The security team should always look for ways to make the development team’s job easier by helping them to develop and deliver software securely. Examples of such help include helping the team to create effective build and deployment pipelines, helping them to come up with a simple process and tools to compile, build, test and automatically deploy the system in ways that also include security checks all along the path.

They may also provide tools for internal training, such as OWASP’s WebGoat Project, the Damn Vulnerable Web Services project or other intentionally vulnerable applications that developers can explore and test so that they can learn about how to find and remediate security issues safely.

The security team may also provide teams with hardened run-time configuration recipes and playbooks, and vetted third-party libraries and images that are free from vulnerabilities which the Agile teams can grab and use right away.

Compliance and Audit. The Agile team would appreciate it if the security team automate the tools and processes used for compliance and audit and make it available using APIs. The Agile team could leverage the APIs to integrate with their tools to perform similar tests to find issues before the audit team does.

Secure Baselines

For the Agile team to have confidence that their product meets a security baseline, the security team should provide baselines and patterns as references. The Agile team should be able to reference such baselines or patterns at each security touchpoint in the Agile lifecycle. They should be able to use the same tools and templates that the security team uses. Such references help the Agile team assert that the build meets the required level of assurance and that every new build in the future would also continue to achieve the same level.

Agile Security Team

For a large enterprise with each LoB having more than 1500 applications in production, it would be challenging to maintain a CSA or an IRM for each application iteration or sprint. To meet the demand of the Agile team, the security team should enable them with tools, baselines, guidance, and patterns. A true agile security team should measure themselves on what they can enable to happen, rather than the security issues they have blocked from getting into production. (Brunton-Spall, Smith, Bird, & Bell, 2017)

Security Tools. The security team should develop security tools that can be used by development teams to assure themselves of the security of their products. The task could be achieved by looking at the risk management tools, attack tree analysis, and Agile story tracking tools. Automated testing tools that fit into the build pipeline, and automatic dependency inspection tools would also help. The tools could also be security libraries or microservices that teams can take advantage of to solve specific problems such as encryption, multi-factor authentication, and auditing. The security team may also develop tools that can safely configure or audit the use of third-party services, such as verifying the correct use of Public Cloud Service features or validating firewall configurations.

The development team should be able to freely pick and choose the tools that fit their build pipeline. In that way, the security team can avoid the culture of compliance where the tool is never understood, and the use of it is forced upon the team. The tools should enable the development team to detect a security defect and find a solution to fix it. It should not be just for detection purpose, making the team to spend more hours finding a fix. The tool should provide guidance to fix the defect, reducing the development team’s research time finding a fix. According to a study at the University of Cambridge, developers spent 50% of their time fixing defects. (Britton, Jeng, Carver, Cheak, & Katzenellenbogen, 2012)

Documenting Security Techniques. The security team needs to teach developers good techniques that are appropriate for the firm. It should cover steps to safely configure a base web application or usage guidance for working with a cloud service provider efficiently and securely. Secure coding guidelines and code review checklists for the languages and frameworks being used would also help. Documenting standard risk lists for the kind of application that the Agile teams are working on would assist them in understanding what controls should be applied in the design and development phase. It is critical that these techniques need to be applicable, timely, and relevant.

Reference Architecture

One of the tools that would significantly help the Agile team is a security reference architecture. It should have a consistent set of architectural best practices for security architecture that is comprehensive and efficient. It should be developed by Cybersecurity Architects and be a guide to the Agile team while being compliant with the firm’s Information Technology policies and standards. The security reference architecture on technology should be a reference for development teams with proven approaches to security risks that utilize best-of-breed products and should be aligned to strategic controls development. It should reduce the team’s excessive amount of time spent on research and increase productivity while reducing the total SDLC cost.

The reference architecture should be a material that is vetted out with all Subject Matter Experts (SMEs) at the enterprise allowing architects to understand what went wrong in previous projects and how to improve them tomorrow. It should enable the firm to socialize and eventually use a common architectural vocabulary across the enterprise.

Conclusion

The combination of iterative and incremental process models with a focus on process adaptability and customer satisfaction by rapid delivery of working software helps Agile methodology to be adopted by large enterprises quickly. There are several agile methods and approaches that software development teams could choose from for the type of products they build. Scrum is by far the most popular agile methodology and is conceptually simple, and can integrate into many existing project and program management frameworks. It is prevalent among managers and senior executives as they feel they can understand more easily what a team is doing, and when they will be finished with a scrum. Kanban is a method for running a high functioning team efficiently. It helps to prioritize how fast a piece of work or workload would travel from the beginning of a system to the end, and the number of touchpoints it should go through.

The security team should always look for ways to make the Agile team’s job easier by helping them to develop and deliver software securely.

References

1. Agil8. (2017). Scrum. Retrieved from agil8.com: https://www.agil8.com/consulting/scrum/
2. Atlassian. (2017). JIRA Software. Retrieved from atlassian.com: https://www.atlassian.com/software/jira
3. Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Grenning, J., . . . Thomas, D. (2001). Manifesto for Agile Software Development. Retrieved August 14, 2017, from Manifesto for Agile Software Development: http://agilemanifesto.org/
4. Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Grenning, J., . . . Thomas, D. (2001). Principles behind the Agile Manifesto. Retrieved August 14, 2017, from agilemanifesto.org: http://agilemanifesto.org/principles.html
5. Britton, T., Jeng, L., Carver, G., Cheak, P., & Katzenellenbogen, T. (2012). Reversible Debugging Software. Retrieved August 16, 2017, from citeseerx.ist.psu.edu: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.444.9094&rep=rep1&type=pdf
6. Brunton-Spall, M., Smith, R., Bird, J., & Bell, L. (2017). Agile Application Security. Sebastopol, CA, USA: O’Reilly Media, Inc.
7. Cornutt, C. (2013, March 20). DREADing your security. Retrieved from websec.io: https://websec.io/2013/03/20/DREADing-Your-Security.html
8. Gibson. (n.d.). Risk management. Retrieved May 5, 2017, from gibsonins.com: http://www.gibsonins.com/risk-management-solutions
9. Howard, P. D. (2006). Assessing Risk. Taylor & Francis Group.
10. Jackson, C., & Carey, M. (2005). The Role of Information Security in the Enterprise Risk Management Structure. In H. Tipton, & M. Krause, Information Security Management Handbook 2005. Taylor & Francis.
11. Microsoft. (2005). The STRIDE threat model. Retrieved from msdn.microsoft.com: https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
12. Mougoue, E. (2016, January 21). SSDLC 101: What is the secure software development life cycle? Retrieved from synopsys.com: https://www.synopsys.com/blogs/software-security/secure-sdlc/
13. Peltier, T. R. (2001). Information Security Risk Analysis. Boca Raton: Auerbach Publications.
14. Peltier, T. R., & Peltier, J. (2004). Complete Guide to CISM Certification. Boca Raton: Taylor & Francis Group.
15. Rouse, M., & Cole, B. (n.d.). Risk management. Retrieved May 5, 2017, from searchcompliance.techtarget.com: http://searchcompliance.techtarget.com/definition/risk-management
16. Stallings, W., & Brown, L. (2015). Computer Security Principles and Practice. Boston: Pearson.
17. Stallings, W., & Brown, L. (2015). Computer Security Principles And Practice. Boston: Pearson.
18. Stephenson, P. (2009). Information Security Essentials. Auerbach Publishing.
19. Stewart, J. M., Tittel, E., & Chapple, M. (2011). CISSP®: Certified Information Systems Security Professional Study Guide, Fifth Edition. Indianapolis: Wiley Publishing, Inc.
20. Stewart, J. M., Tittel, E., & Chapple, M. (n.d.). CISSP®: Certified Information Systems Security Professional Study Guide, Fifth Edition. Indianapolis: Wiley Publishing, Inc.
21. TechBeacon. (2017, August 17). Scrum vs. Kanban: How to combine the best of both methods. Retrieved from techbeacon.com: https://techbeacon.com/scrum-vs-kanban-how-combine-best-both-methods
22. Tipton, H., & Krause, M. (2005). Information Security Management Handbook. CRC Press.
23. Tutorial Point. (2017). SDLC- Agile Model. Retrieved August 14, 2017, from tutorialspoint.com: https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm

The field of cybersecurity involves application security, information security, network security, disaster recovery or business continuity planning, operational security, and security awareness and training — these supplement physical security which is the traditional field of security that protects physical locations and assets.

According to Forbes (Bradford, 2017), the average salary in Cybersecurity is $116,000 or approximately $55.77 per hour in 2017. Depending on the role it could go up or down. Such positions include Security Analyst, Risk Manager, Security Architect, Security Engineer, Security Testers, and Chief Information Security Officer (CISO) at a high level.

If you have a passion for writing code and building applications, a natural career move is to be in application security. It is the use of software, hardware, and procedural methods to protect applications from external threats. The IBM System Science Institute (Dawson, Rahim, Burrell, & Brewster, 2010) estimates that the cost to fix a bug found in production is around six times costlier than one identified during design. Application Security practitioners help to identify vulnerabilities in the design, code, and binaries early on in the System Development Life Cycle (SDLC). The ideal candidate for this practice is someone who has software development experience with training in methodologies such as Static Application Software Testing (SAST), Dynamic Application Software Testing (DAST), and Penetration Testing. Some of the certifications that would help to get into this field are Certified Secure Software Lifecycle Professional (CSSLP) and Certified Ethical Hacker (CEH).

Individuals whose experience includes Project Management and Architecture would find Information Security exciting where they would come up with a set of strategies for managing the processes, tools, and policies necessary to prevent, detect, document, and counter threats to digital and non-digital information. As Risk Managers and Security Architect, their primary goals are to protect confidentiality, integrity, and availability of information. Certifications such as Certified Information Systems Security Professional (CISSP), Certified Information Security Manager (CISM), and Certified in Risk and Information Systems Control (CRISC) would help in getting into this practice.

Those who have been practicing network administration would make a good choice in Network Security where they would engage in design activities to protect the usability and integrity of computer networks and the data that goes through them. They deal primarily with network access controls and segmentation to protect data from unauthorized access and maintain its integrity while making it available to those who need to have access. Having Cisco or similar network certification along with CISSP would help to get into the network security practice.

Disaster recovery or business continuity planning is the practice in which practitioners determine the essential functions of the business, identify which systems and processes must be sustained, and details how to maintain them. The method involves anticipating natural and other disasters that could cause significant impact to the business, planning for “Plan B” to sustain business operations, and continuously testing them. Certifications that helps to get into this practice include Certification of the BCI (CBCI), ISO 22301 Certified Business Continuity Manager (CBCM),
Certified Business Continuity Professional (CBCP), Certified Disaster Recovery Engineer (C/DRE), and EC-Council Disaster Recovery Professional (EDRP).

OPSEC (operational security) is an analytical process that classifies information assets and determines the controls required to protect these assets. (Rouse & Cole, 2016). It describes strategies to prevent potential adversaries from discovering critical operations-related data. As information management and protection has become crucial to success in the private sector, OPSEC processes are now standard in business operations. OPSEC encourages managers to view operations or projects from the outside-in, or from the perspective of competitors (or enemies) to identify weaknesses. Developing the art of Threat Modeling and Risk Management is essential in this practice. CISSP with appropriate education and experience, usually in the Military or Department of Defense, would benefit from this practice.

Have that passion for developing training materials and training people? Security Awareness and Training is looking for you. It involves educating employees about corporate policies and procedures for working with information technology (IT). The security awareness practitioners would provide information to employees on who to contact if they discover a security threat and would educate them that data is a valuable corporate asset. It would always help to have a CISSP when looking for a position in this area.

Today many reputed universities offer formal education in cybersecurity, information security, and information assurance. Some of them are geared for the tech-savvy while others are for mid-career professionals who are looking towards career growth in the management side of cybersecurity. I would recommend those that are recognized as the Center of Academic Excellence in Information Assurance Education by the National Security Agency (NSA) and the Department of Homeland Security (DHS).

Cybersecurity is here to stay. Professionals are always required in cybersecurity as long as there are adversaries. With the right talent and skill, an individual should not have difficulty finding a career in cybersecurity. According to Forbes, there will be as many as 3.5 million unfilled positions in the industry by 2021. (NeSmith, 2018) So why wait?

References
– Bradford, L. (2017, February 27). How To Start A Lucrative Career In Cybersecurity. Retrieved from Forbes: https://www.forbes.com/sites/laurencebradford/2017/02/27/how-to-start-a-lucrative-career-in-cybersecurity/#14b17b1f1066
– Dawson, M., Rahim, E., Burrell, D. N., & Brewster, S. (2010). Integrating Software Assurance into the Software Development Life Cycle (SDLC). Journal of Information Systems Technology and Planning., 49-53.
– NeSmith, B. (2018, August 9). The Cybersecurity Talent Gap Is An Industry Crisis. Retrieved from Forbes: https://www.forbes.com/sites/forbestechcouncil/2018/08/09/the-cybersecurity-talent-gap-is-an-industry-crisis/#59005c36a6b3
– Rouse, M., & Cole, B. (2016, July). OPSEC (operational security). Retrieved from TechTarget: https://searchcompliance.techtarget.com/definition/OPSEC-operational-security

As someone who volunteers for non-profits, I have the opportunity to try out Gmail from G-Suite. As of today (August 25, 2018), Google is yet to provide documentation for Amazon Lightsail DNS.

What you need to do is add your domain name to that field.

Try checking if the records are propagated using https://www.whatsmydns.net/

Don’t forget to add SPF and DKIM records

According to a Gartner research paper, “Two firewall platforms are not better than one. We believe there is a higher risk associated with configuring and managing firewalls from multiple vendors than from a single vendor. Therefore, Gartner advises enterprises that have more than one firewall to standardize on a single vendor platform when the opportunity presents itself (that is, new installations or replacement during a refresh). In choosing a standard firewall, enterprises should consider the experience of their firewall administrators with each platform, scalability, central management, and cost. ” (Young & Pescatore, 2008)

It also says that a firewall misconfiguration causes more than 99% of firewall breaches; not firewall flaws. It is true that debugging an error in any new appliance or tool can be cumbersome and time-consuming. Moreover, narrowing down to a single vendor relationship could help with greater discounts with less administration overhead.

However, there are situations where an enterprise could be stuck with a solution for long without much help to upgrade unless the enterprise pays almost the cost of a new solution and the extra cost of migrating to it. Sometimes it is better to diversify, especially when the industry is drastically changing and not all vendors address all issues with the changes.

Reference:

• Young, G., & Pescatore, J. (2008, August 12). Q&A: Is It More Secure to Use Firewalls From Two Different Vendors? Retrieved October 13, 2016, from TechData: http://www.techdata.com/techsolutions/networking/files/june2010/gartner%20firewall%20page%207%20qa_is_it_more_secure_to_use__160362.pdf

“Firewalls actually come in two distinct flavors: software applications that run in the background and hardware devices that plug in between your modem and one or more PCs. Both types hide your PC’s presence from other systems, prevent unauthorized access from external sources, and keep tabs on network traffic across the firewall.” (Desmond, 2004)

The host-based software firewalls are good for the host; but not for the network that the host is connected to. A hardware-based firewall is required for:

1. Network address translation (NAT) to prevent exposure of internal IP addresses,
2. Port management to close unsolicited access to your host,
3. Stateful packet inspection (SPI) to inspect for unsolicited incoming traffic,
4. Virtual private network to support connection remote connection and the host,
5. Activity logging and alerts
6. Content and URL filtering

The hardware-based firewall is easy to implement and saves computing resources on the host. Malware on the host can bring down the firewall on the host, but not the hardware firewall.

While the hardware-based firewall can protect threats from outside the network, the software-based firewall helps to protect from attacks within the system. Software-based firewalls help to detect unauthorized outbound traffic from the host. A user can pick and choose which application can talk to peer hosts as well as external systems and may not be able to do this with hardware-based firewalls.

Reference:

Desmond, M. (2004, November 25). What You Should Know About Firewalls. Retrieved October 10, 2017, from PCWorld: http://www.pcworld.com/article/117557/article.html

I believe it is essential to acknowledge the risk. We need to document it as very low risk, and very minimum safeguards are required as part of risk assessment. The building code of the location would define minimum safeguard. However, there could be situations where the asset value of the site is very high that you cannot ignore the risk altogether. Say the location is the primary data center for the organization. In such situations, the organization must implement all appropriate controls required to protect from the flood. The assessment needs to be revisited periodically to determine if the risk is significant or not at that time. Each evaluation must be based on current facts and numbers at the time.

While the evolution of ARPANET, to Ethernet and then to Internet happened, enterprises were discovering new ways to compute from mainframes to multi-tier computing. During the early stages of enterprise computing, enterprises were purchasing hardware and software to host internally. Though not in the form that we see today, enterprises had an early version of cloud in the form of networked mainframe systems with dumb terminals. They then slowly began to outsource their information systems to Internet Service Providers (ISPs) and Application Service Providers (ASPs).

The concept of using computing, as a utility was probably first proposed by Professor Noah Prywes of the University of Pennsylvania in the Fall of 1994 at a talk at Bell Labs. “All they need is just to plug in their terminals so that they receive IT services as a utility. They would pay anything to get rid of the headaches and costs of operating their own machines, upgrading software, and what not.” (Faynberg, Lu, & Skuler, 2016). It came to fruition when Amazon launched its limited beta test of Elastic Cloud Compute Cloud (EC2) in 2006. Meanwhile, Salesforce.com has already mastered how to deliver an enterprise application using a simple website.

The author has been involved with cloud computing since 2009. However, at that time there was no precise industry definitions or standards as we see today from National Institute of Standards and Technology (NIST). This essay is an attempt to look at where we are with cloud computing today.

What is Cloud Computing?

There are many definitions of cloud computing. However, the most commonly used one is that of National Institute of Standards and Technology (NIST) in its Special Publication 800-145. According to NIST, Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. (Mell & Grance, 2011)

NIST categorizes cloud computing into five essential characteristics, three service models, and four deployments.

Cloud Service Provider

Any organization that offers services with the essential five cloud characteristics defined by NIST and has one of the service models to support an individual or enterprise entity deploy a solution in the cloud is a Cloud Service Provider (CSP).

Cloud Service Customer

Any individual or enterprise entity that consumes the services of a Cloud Service Provider to deploy a solution as defined in NIST cloud deployment model is a Cloud Service Customer (CSC).

Cloud Service Providers can be characterized using the essential characteristics and service models defined by NIST. (Mell & Grance, 2011)

Essential Characteristics of Cloud as defined by NIST

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

Cloud Service Models as defined by NIST

Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer can deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Cloud Service Providers

Some of the well-known CSPs are Amazon AWS, Google Cloud Platform, IBM Cloud, and Microsoft Azure.

Amazon AWS. The AWS pricing is a pay-as-you-go model for more than 60 of its cloud services. Customers pay only for what they use rounded to one hour. They could pay in advance and can avail Amazon’s incentives if more and more of its resources are being consumed. A CSC can estimate their cloud cost upfront using their Simple Monthly Calculator. Though most of its services have short-term contracts, Amazon offers a discount for long-term locked-in agreements with Reserved Instance (RI) especially the EC2 and RDS services. Amazon’s support billing is based on each account usage. (Amazon AWS). Amazon AWS has their own Linux version for the cloud and charges extra for Microsoft Windows.

Google Cloud Platform. Google has no contract with their pricing model. However, they offer automatic discounts for loyal customers with the sustained use of their service. They have a per-minute billing that supports “greater business agility.” Enterprise doesn’t need to estimate and pay-up for what they will be using in future. They only need to pay for the time they use Google resources and could calculate their payment using their TCO Pricing Calculator. (Kaufmann & Dolan, 2015) Google Cloud does not offer dedicated hosts.

IBM Cloud. Unlike the network of IBM mainframes that enterprises had, the new cloud allows enterprises to build cloud application on custom configured hardware on bare-metals. (Wayner, 2016) The Big Blue lets you have public cloud your way with bare metal, private instances, and even custom-configured hardware options. What stands out at IBM Cloud is its application store from where its customers can pick and choose desired applications to come up with new innovative products and services that can adapt to the market needs. (Satell, 2015) Since the IBM Cloud is offered as IaaS, its CSCs has the liberty to use its application on IBM Bluemix PaaS platform or use a third-party application. IBM Bluemix only supports Java. IBM Cloud offers two types of pricing – either (1) reserve capacity with a contract for 6 to 12 months with reduced pricing or (2) pay-as-you-go for each service utilized.

Microsoft Azure. The only CSP that offers Windows with no charge along with Linux support is Microsoft Azure. This attracts enterprises that are rooted in Microsoft technologies. (Wayner, Cloud review: Amazon, Microsoft, Google, IBM, and Joyent, 2016).  The cost of using their cloud platform could be relatively high compared to other providers, and the overall performance of the cloud is rated average. Nevertheless, its cloud is regarded as one of the clouds where enterprises could get up and run quickly with its easy to use user interface. Due to its downtimes reported in 2014, some enterprises are still waiting for its cloud to mature. (Vuaghan-Nichols, 2015).

Deployment Model

All of the above CSPs offer services through virtualization at infrastructure, platform and application level.

Public Cloud. Cloud services, as described above, when available to a customer on the Internet as a utility are called the Public cloud.

Private Cloud. While the Public cloud offers significant cost reduction, enterprises have started virtualizing their internal infrastructure, platform and applications to further reduce their cost and avoid paying an external party. These clouds are called the Private cloud.

Hybrid Cloud. Some enterprises may combine a public cloud stack (e.g., long-term data object storage in Amazon S3) with a private cloud stack to form what is known as the Hybrid cloud. They pick and choose best of both worlds to develop a solution for their customers.

Community Cloud. A cloud built to solve a particular problem in a community of consumers is called Community Cloud.

Architecture

Virtualization. Virtualization helps the CSP to save cost on space, energy, and personnel while increasing CPU utilization. In the traditional enterprise computing, the CPU is never utilized to its full capacity. Virtualization also helps in cloning the master image for testing or debugging purpose. The cloned Virtual Machine (VM) image could be sitting on the same virtualized infrastructure, while isolated from the master image, reducing hardware cost for the CSC. Isolation offered through virtualization improves the security of the virtualized image provided the virtualized environment, and the image are hardened. CSC could scale up or down the number of isolated images depending on the demand of its users, and the CSC needs to pay the CSP only for the space it uses for having the images, the bandwidth for interacting with the images, the time it used its application and infrastructure services and the energy needed to sustain the demand for its resources. CSC can do all these with minimum CSC personnel interaction because of the automation available at the CSP. CSC need not hire dedicated system administrators to host its solution as long the solution developer know how to configure its tenancy in the cloud.

Virtualization is possible using hypervisors. There are two types of hypervisors. Those that run directly on the physical machine is Type-1 or bare-metal hypervisors. Hypervisors that runs on top of an operating system are Type-2 hypervisors.

Xen hypervisors are Type-1 and are not dependent on an operating system. It can concurrently run Virtual Machines (VM) with the different operating system. Another Type-1 hypervisor is KVM that also supports a guest-operating model. Unlike Xen, KVM creates a VM as Linux process. Both Xen and KVM are open source projects. VMWare Workstation and Oracle VM VirtualBox are commercially available Type-2 hypervisors. (Faynberg, Lu, & Skuler, 2016)

Since cloud computing is heavily dependent on virtualization, the security of the virtualized environment is paramount for its tenants. Tenants need to assume that the hypervisors are always susceptible to threats from other tenants as well as from the host when they design their solutions. The same is true for the host on the other side of the coin. The host of the virtualized environment needs to ensure that their network, infrastructure, platform and software used for internal operations are not threatened. The NIST Special Publication 800-125-A provides security recommendations hypervisor deployment. (Chandramouli, 2014)

Data Network. A set of technologies that enables communication between two processes located on different computers is Data Networking.  Without the evolution of data networking, the cloud wouldn’t be where it is today. Cloud Computing leverages physical interconnection within the cloud, between any two federated clouds as well as between any computer that needs to access the cloud and the cloud itself. Operating Systems in the cloud manages these communications using Internet Protocol (IP), Multi-Protocol Label Switching (MPLS), Virtual Private Network (VPN) and Software Defined Network (SDN) leveraging appliances such as Domain Name System (DNS) with load balancing and Network Address Translation (NAT) for deceptive controls, and firewalls for resistive security controls. (Shimeall & Spring, 2014)

Database and Storage. In Cloud Computing, virtualization of infrastructure leads to virtual data centers with no well-defined physical boundaries. These virtual data centers are intended to host multiple tenants. Some virtual data centers may span into numerous physical data centers especially in hybrid clouds. Depending on the connection to the host, clouds may have three types of storage: (1) direct-attached storage, (2) network attached storage and (3) Storage Area Network (SAN). Direct-attach storage is easy to store data but challenging to share. That’s where network attached storage helps. It helps to share a file over IP network. However, network attached storage does not work well with databases. It also has storage throughput limitations due to underlying networking media. SAN addresses such problems. To enable resource pooling, storage resources need to be virtualized simplifying management tasks such as database snapshots and migration.

Amazon offers Relational Database (RDS) that allows it to run MySQL, Oracle or SQL Server. It also provides schema-less database called Amazon SimpleDB for lighter workloads. Amazon DynamoDB is its solid-state drive (SSD) backed database with high replication capability. Google Cloud SQL is a MySQL-like relational database from Google while Google BigQuery is an analysis tool for querying large data sets stored in the cloud. Microsoft offers its SQL server either in the cloud or a VM. IBM offers its IBM Cloudant, which is a NoSQL data service. It also provides its powerful DB2 in the cloud. Some of these databases are used for their own data storage purposes. Some of the CSPs (not the ones mentioned above), especially the SaaS providers have nothing but a floor and couple of laptops. Everything else is in the cloud including their data.

Applications. Applications that can be re-used again and again by consumers from the Internet are good candidates for the cloud. However, not all applications should be in the cloud. Enterprises must be very cautious about putting applications that process highly sensitive data with personally identifiable information in the cloud. Because of its multi-tenancy characteristics, there is always a chance for a tenant to see other tenant’s data. Sometimes building a private cloud is better than sending everything to the public cloud. Some enterprises use dedicated MPLS line between the public IaaS and its private cloud to leverage the computing power of the public IaaS. This hybrid model mitigates direct threats from the Internet. However, it is still susceptible to threats from the cloud tenant; maybe with a short window of opportunity.

Locations. Depending on where the tenant is, or where CSC operates its business, or where the data originates, the data contained in the cloud are subject to the laws and regulations of the countries where they are in. In the US, various states such as Massachusetts and California have privacy laws while there are markets subject to industry regulations such as Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standards (PCI DSS). Canadian entities or custodians of data originating from Canada must adhere to Canadian Personal Information Protection and Electronic Documents Act (PIPEDA or the PIPEDA Act) while also complying with PCI DSS if they are processing credit cards.

Supply Chain. Depending on the deployment model, there could be multiple CSPs in the supply chain from a CSC perspective. A CSC might be using a SaaS application that is sitting on top of PaaS provided by another entity. The PaaS may be sitting on top of an IaaS that may be sitting in a different country. The data that CSC sends to the cloud is now subject to laws and regulations of two different countries and may be of multiple industries (e.g., Health and Payment Card).

Data Security

Since Cloud Computing combines multiple technologies, security needs to be approached by understanding the threats, measuring the risk and applying mitigating controls at (1) each technology stack, (2) service model level, and (3) end to end solution level.

CSP Perspective. From a CSP perspective, the confidentiality, integrity, and availability of its configuration data are paramount as it is what gives its competitive edge. This intellectual property must be protected as the most valuable data asset in the company. Enterprise also needs to ensure data security of its employees, customer, and partners. It also needs to protect intellectual properties such as research materials, code, market analysis, etc. CSP must employ access controls, data-in-transit as well as data-at-rest encryption, network segregation and zoning to protect its data. CSP need to ensure infrastructure, operating systems, databases and data stores that they use for internal operations are separate from that of their customers to reduce threats originating from the CSC. The separation must be in such a way that a CSC must not be able to see CSP assets at all. This could be done through a complete air gap between CSP internal operations assets and CSC assets.

CSC Perspective. The CSP would have to deploy security controls to protect CSC data depending on the sensitivity of the data that it sends to the cloud, the location of the owner of the data and where it will reside. These include, but not limited to, access controls, data-in-transit as well as data-at-rest encryption, network segregation and zoning to protect its data. When designing a solution for the cloud, CSC must consider all possible threats to its application and apply required mitigating controls. It must consider all threats to its data from other tenants in the cloud as well as from the host. The CSC must develop controls to protect its data assuming the attack can happen anytime.

Conclusion

The business of cloud computing has come a long way. As more and more enterprises are adopting cloud computing, the should be able to use the guidance provided by NIST and Cloud Security Alliance. While enterprises continue to perceive hosting sensitive data outside their network as a risk, the cloud service providers would continue to perfect their security controls to build the confidence of their consumers. Each of them is trying their best to protect their assets.

“Do not figure on opponents not attacking; worry about your lack of preparation.” – Sun Tzu, The Art of War

References

• Amazon AWS. (n.d.). AWS pricing. Retrieved from Amazon AWS: https://aws.amazon.com/pricing/
• Architect, C. S. (2016, September 22). Executive Director. (S. A. Jabbar, Interviewer)
• Chandramouli, R. (2014, October). Draft Special Publication 800-125A, Security recommendations for hypervisor deployment. Retrieved from NIST: http://csrc.nist.gov/publications/drafts/800-125a/sp800-125a_draft.pdf
• Faynberg, I., Lu, H.-L., & Skuler, D. (2016). Cloud computing. West Sussex: John Wiley & Sons.
• Kaufmann, A., & Dolan, K. (2015, June). Pricing comparison: Google Cloud vs. Amazon Web Services. Retrieved from Google Cloud Platform: https://cloud.google.com/files/esg-whitepaper.pdf
• Mell, P., & Grance, T. (2011, September). NIST SP 800-145, The NIST definition of cloud computing. Retrieved from National Institute of Standards and Technology | NIST: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
• Satell, G. (2015, April 27). Move Over Amazon, IBM Can Also Claim Top Spot In Cloud Services. Retrieved from Forbes: http://www.forbes.com/sites/gregsatell/2015/04/27/move-over-amazn-ibm-now-rules-cloud-services/#578aa4dd6dad
• Shimeall, T. J., & Spring, J. M. (2014). Introduction to Information Security. Waltham: Syngress.
• Vuaghan-Nichols, S. J. (2015, December 14). Microsoft Azure. Retrieved from PCMag: http://www.pcmag.com/article2/0,2817,2496295,00.asp
• Wayner, P. (2016, January 27). Big Blue lets you have public cloud your way with bare metal, private instances, and even custom-configured hardware options. Retrieved from InfoWorld: http://www.infoworld.com/article/3026459/cloud-computing/review-ibm-cloud-is-built-to-order.html
• Wayner, P. (2016, April 20). Cloud review: Amazon, Microsoft, Google, IBM, and Joyent. Retrieved from InfoWorld: http://www.infoworld.com/article/3057586/cloud-computing/cloud-review-amazon-microsoft-google-ibm-and-joyent-compared.html?upd=1474473847708
• Whitman, M. E., & Mattord, H. J. (2016). Principles of Information Security. Boston: Cengage Learning.

Employees are doing a favor for the company and its stakeholder by raising concerns about unethical or illegal behaviors. One day or the other, the act will come to light, and it will cost the company its reputation on top of legal suits, regulatory penalties, settlement costs and loss of market share.

The latest on Volkswagen (VW) diesel emissions scandal is that “Volkswagen has agreed to pay almost $15 billion to settle claims in the United States, and it must buy back or fix affected vehicles by December 2018. As part of the settlement, more than $10 billion has been set aside to buy back the roughly 475,000 Volkswagens and Audi A3 models that have 2-liter engines.” (Gates, Ewing, Russell, & Watkins, 2016)

According to the article, “Volkswagen has set aside 16.2 billion euros, or about $17.9 billion, for costs related to the scandal.” Had someone at VW raise the concern at the right time to the right people in VW management, this could be avoided.

However, Los Angeles Times says, “Schneiderman’s investigation found it “was clear” that current Volkswagen Chief Executive Matthias Mueller knew about emissions issues in July 2006, the attorney general told reporters Tuesday. Other top VW executives, including former CEO Martin Winterkorn, knew about the deception and participated in efforts to cover it up, the New York lawsuit said.” (Associated Press, 2016)

The Los Angeles Times articulates that the executives at VW were colluding and I am sure whoever raised their concern to the management would have faced adverse retaliation.

“A recent review of whistleblowing incidents shows that among the whistleblowers surveyed, 62% lost their jobs, 18% felt that they were harassed or transferred, and 11% had their job responsibilities or salaries reduced. Fifty-one percent of the incidents resulted in external investigations of the companies involved, 37% in management shake-ups, 22% in criminal investigations, and 11% in indictments. Although these outcomes may not be typical, they do point out the potential seriousness of whistleblowing.” (Barnett, 1992)

I believe enterprises who have learned their lesson the hard way has already started setting up hotline service for anyone who wants to raise concern. They are promised to be kept anonymous, and the enterprise takes immediate actions.

References:

• Associated Press. (2016, July 19). Volkswagen CEO knew of emissions trouble 10 years ago, prosecutor says. Retrieved from Los Angeles Times: http://www.latimes.com/business/autos/la-fi-hy-vw-audi-porsche-20160719-snap-story.html
• Barnett, T. (1992). Why Your Company Should Have A Whistleblowing Policy. Retrieved from ethics.csc.ncsu.edu: https://ethics.csc.ncsu.edu/old/12_00/basics/whistle/rst/wstlblo_policy
• Gates, G., Ewing, J., Russell, K., & Watkins, D. (2016, July 19). How Volkswagen’s ‘Defeat Devices’ Worked. Retrieved from New York Times: https://www.nytimes.com/interactive/2015/business/international/vw-diesel-emissions-scandal-explained.html?_r=0

The management of an institution could be the owner or custodian of the data that their information security program is trying to protect. They need to ensure that the systems they employ execute all the functions on the data as they are supposed to while ensuring the data is not leaked to unauthorized personnel. “Primary mission of an information security program is to ensure information assets-information and the systems that house them-remain safe and useful” (Whitman & Mattord, 2014)

Management is responsible for the reputation of the business, it’s proper functioning, the data it holds, and safeguarding the technology it uses. However, all these could be impacted if the technology that they deploy do not meet the requirements – functional as well as non-functional. Technology is only a tool that facilitates proper function of the business providing value to its customer and keeping track of all its transaction. Technology must be configured in such a way that the data that the business holds is protected while in transit, at rest and in process.

So, should the Chief Information Security Officer (CISO) report to Chief Information Officer (CIO) or the Chief Executive Officer (CEO)? “Once an organization’s infrastructure is in place, management must continue to oversee it and not relegate its management to the IT department” (Whitman & Mattord, 2014), the management of information security should not be under IT (CIO). If left under IT, the programs and processes that the CISO comes up with would be limited within the constraints of the IT department. The CISO may not be able to comprehensively bring people, process and technology.

The Information Security Management Program, when moved out of IT umbrella and put under CEO, would have direct oversight of the board and would not be limited in performing audits and independent review of IT and its processes. If needed, the CISO could bring non-IT departments such as intellectual property, legal, vendor management and asset management into their processes without impacting IT.

Reference:

• Whitman, H. J., & Mattord, M. J. (2014). Principles of Information Security 5th edition. Boston: Cengage Learning.

The only person who need not worry about information security is the one who has no value bearing data. Unfortunately, in this day and age, every single person who is connected to modern world has some data that is valuable either to the individual or someone else. Protecting that valuable informational data from a compromise is paramount depending on its value.

According to Verizon, “No locale, industry or organization is bulletproof when it comes to the compromise of data.” (Verizon, 2016) I would add “no connected person” to that list.

Though external threats cause most of the data breach, a little less than 20% occurs due to internal threats (someone you know) and most of them are financially motivated (a little more than 75%). Most of the attacks are targeted at non-technical users – the ones that use the computer to send an email or the ones that use the ATM to get some cash for their day to day purpose. They may not have value bearing data that an adversary is looking for, but they may have something that is informational.

A person need not explicitly use technology to give up information. Mere interaction with technology or even social interaction with the adversary could cause a data breach. The value of data depends on how much the adversary can understand it.

Reference:

• Verizon. (2016). 2016 Data Breach Investigations Report. Retrieved from verizonenterprise.com: http://www.verizonenterprise.com/resources/reports/rp_DBIR_2016_Report_en_xg.pdf