Showing posts with label blog. Show all posts
Showing posts with label blog. Show all posts

Wednesday, September 16, 2015

Strategizing On Shifting Left Security In The SDLC


#SridharPeddisetty #InformationSecurity #Security #Strategy #Social #Mobile #Analytics #Cloud #IoT #SMAC
“If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.” – Bruce Schneier

Introduction

Most of the Organizations still continue to have a reactive approach towards information security. In my earlier blog post 7 Reasons No Company Can Afford To Ignore Security, I had shared why Organization’s can no longer afford to ignore security and in 6 Steps Strategizing Security In An Organization shared on how to strategize security in 6 steps. Its important for organizations to have a proactive security strategy and have a shift left practice in software development lifecycle (SDLC) to focus on security right from the initiation state of a project. Integrating security in the SDLC helps in the accountability and increased communication with all stakeholders involved in the process to ensure the project is incorporating security policies while following the security guidelines

Why shift left security in the SDLC?

In the traditional SDLCsecurity strategy is always reactive in which the security testing is done at the end of development phase. If any security issues are found then, it becomes expensive to resolve and more often than not, due to time or financial constraints, quick patches are done or short term mitigations are put in place before releasing the software into production. More often than not, short term mitigations or patches result in costly expenses for maintaining security as the cost of operations are high. According to the study done by Cigital, cost of finding issues early during SDLC development phase results in upwards of 1165% savings when compared to finding issues during maintenance phase of SDLC.  

Strategizing on shifting left security in the SDLC 

Below is how we can strategize security by shifting it left in the SDLC. Incorporating security in each phase of SDLC helps an organization be more proactive in implementing a highly secured software. Moreover, overall costs are reduced as the security issues are found early in the development lifecycle. Security governance model established in the initiation phase helps define the security gates, policies, roles & responsibilities, timing of review, sign off process, etc. in each phase which governs security throughout the SDLC. Note that the Security Trainingis a continuous process throughout the SDLC so that the teams are constantly aware of security policies, protocols, tools, etc.

Summary

By shifting security left in the Software Development Lifecycle (SDLC), it helps in building more secured software and addresses the security compliance requirements while reducing overall cost. 
I will be sharing more inputs on Information Security including how to align Secured Software Development Lifecycle (SDLC) using Agile or Waterfall methodology and how security can be trained, initiated, planned, analyzed, designed, implemented and maintained. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com
Strategizing On Shifting Left Security In The SDLC was originally posted under Prokarma Blog 

Tuesday, September 15, 2015

6 Steps Strategizing Security In An Organization



#SridharPeddisetty #InformationSecurity #Security #Social #Mobile #Analytics #Cloud #IoT #SMAC

"Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." — Gene Spafford (in e-mail to organizers of a workshop on insider misuse)

Introduction

For any organization, security is the collection of technologies, standards, policies, regulations and management practices that are applied to systems and respective data points to keep them secured. In my earlier blog post 7 Reasons No Company Can Afford To Ignore Security, I shared why organizations can no longer afford to ignore security. It's important for organizations to have a proactive security strategy in place for reasons inclusive of:
  • Present business operations of an organization increasingly vulnerable to risk,
  • Security threats from mobile & web interactions with corporate systems,
  • Ever-expanding regulations, and
  • International access points requiring organizations to be complaint with regulations and law of the land

  6 Steps Strategizing Security In The Organization


I will be sharing more inputs on Information Security including how to align Secured Software Development Lifecycle (SDLC) using Agile or Waterfall methodology and how security can be trained, initiated, planned, analyzed, designed, implemented and maintained. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com.

Wednesday, September 9, 2015

7 Reasons No Company Can Afford To Ignore Security


#SridharPeddisetty #InformationSecurity #Security #Social #Mobile #Analytics #Cloud #IoT #SMAC
"It used to be expensive to make things public and cheap to make them private. Now it’s expensive to make things private and cheap to make them public." — Clay Shirky
Today, technology is becoming core for any business and companies that are becoming more dependent on their information systems, with threats to public and personal data increasingly more real. To have an edge over their competition and with companies investing heavily on SMAC (Social, Mobile, Analytics & Cloud) and Internet of Things (IoT), they are exposing their business to new forms of information security risks. More often than not, companies have a very reactive approach to security in which there is minimal security strategy in place if none at all.
The following 7 reasons are important to understand and know that no company can afford to ignore security in today’s changing landscape of disruptive innovation with technologies and processes.
#1. Financial losses: Security breaches can lead to business interruptions, which directly impacts the financials of a company. An attack that leads to downtime for a data center can cost businesses nearly $8,000 per minute. Considering that the average downtime for each incident is almost 1.5 hours, companies stand to lose almost $700,000 due to downtime.
#2. Intellectual property theft: Even though companies are becoming better at protecting themselves from an outside threat, the view is that theft of intellectual property more often happens intentionally or inadvertently by the existing employees. Social media is the biggest medium through which free-flowing data leakage could happen. Phishing scams, whereby attackers try to elicit information from individuals, pose a significant threat as well.
#3. Damage to the reputation: In today’s world, reputation risk ranks among companies’ top strategic risks, and security is one of the primary drivers of reputation risk. According to The Reputational Impact of IT Risk

  • 46% of organisations suffered damage to their brand reputation and value, as a result of a security breach and
  • 19% of organisations suffered damage to their brand reputation and value, as a result of a third-party security breach.

#4. Fraud: General perception is that fraud happens mainly in banking and online retail shopping but the fact remains that all companies are vulnerable to fraud. Almost all companies use systems for online transactions, which are always vulnerable for attacks where hackers do major fraud. Unfortunately, today there is less protection for recovery of stolen funds under the law for businesses than for consumers, which makes companies more prone. 
#5. Extortion: Number of extortion cases are on the rise with extortionist groups threatening companies that their web sites would face a distributed denial-of-service (DDoS) attack if they do not pay ransom. Recent Ashley Madison data breach is an example of how a company can be extorted and the irreversible damage it could cause to the company and its stakeholders. 
#6. Loss of shareholder value: Highly publicized data breaches at Sony PicturesAnthem InsuranceAshley Madison and other major businesses continue to put loss of shareholder value at high risk. Ashley Madison CEO quit after the data breach, which caused a major loss of shareholder value. 
#7. Legal Implications through lawsuits: In recent times, companies have experienced possible damages due to lawsuits from security breaches and the overall loss of customers. The average cost for a legal defense stands at half a million dollars, while the average cost of a settlement reaches seven figures at one million dollars. Again Ashley Madison is a good example of the legal implications affecting the company. 
Let us not look back in anger or forward in fear, but around in awareness— James Thurber
I will be sharing more information on Security including how to strategize and plan for Security, Risk and Compliance. Also sharing how to align Secured Software Development Lifecycle (SDLC) using Agile or Waterfall methodology and how security can be trained, initiated, planned, analyzed, designed, implemented and maintained. Meanwhile let me know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com 
7 Reasons No Company Can Afford To Ignore Security was originally posted under Prokarma Blog on Sep 8th 2015

Tuesday, September 8, 2015

Metrics For Maximizing Productivity In Kanban SDLC


#SridharPeddisetty #Agile #Kanban #SDLC #Productivity #BestPractices #Metrics #EngagementManagement

“Measure what is measurable and make measurable what is not so” –Galileo

In my earlier post Kanban & DevOps - Forming a Perfect Alliance, I had shared the basics of Kanban. In this post, we will look at the metrics for identifying bottlenecks while using Kanban as the software development lifecycle (SDLC) methodology. With experience and motivation to improve quality comes working out the right metrics, which measures areas of continuous improvements. In my earlier post 10 Ground Rules on the Right Metrics for Your Business, I had shared some rules on selecting the right metrics that is tied to the desired business outcomes. As summarized in the blog post, data collection, analysis & management is most often cost and labour intensive, so its important to always weigh in against the benefit derived from the selected metric.

One important principle of Kanban is to maximize productivity by optimizing the flow of work and managing work in progress (WIP) by removing bottlenecks. Before selecting the metrics, we need to assess what metrics is needed and then plan on using the processes and tools, which will provide the data for quantification in a shape and form that will allow us to measure. Presently Organizations are competing to provide faster value to their customers, which is effectively done by sizing and decomposing the requirements into minimal marketable features (MMF).

In Kanban, we can have have the Kanban board visualizing the WIP for states and swim-lanes. States could represent the following phases a user story (feature) or defect goes through the development lifecycle
  • Product Backlog (Requirements)
  • Defined (Analyzed) 
  • In Progress (Development & Testing)
  • Completed
  • Accepted  
while the swim-lanes could represent WIP for 
  • Expedite (Priority) user stories or
  • Defects (Severity 1/2) or
  • Different functional groups such as
    • Architecture,
    • UI/UX Designers,
    • Business Analysts / System Analysts, 
    • Development 
    • Operations
    • DevOps
    • QA
    • Technical Writers
    • others  
In some cases, Kanban board can represent one swim-lane for both expedite and non-expedite user stories or defects while just visualizing states.

Below is a sample ‘Cumulative Mean Lag Time’ metrics, which is measuring the time spent by a user story (USxxxx) or Defect (DExxx) both expedite or non-expedite in each of the following state
  • Requested,
  • Defined,
  • In Progress,
  • Peer Review,
  • In QA, 
  • In UAT and
  • On Hold


From the metrics we can derive following information including identifying bottlenecks and areas of continuous improvement
  • Expedite user stories (US7000 & US7674) are obviously prioritized by the team as the time spent in each state was short comparatively, thus faster overall cycle time. Information can be derived from the chart if the expedite items are distracting the team in effecting their WIP items by looking at the mean lag time an item is spending in each of ‘Defined’ or ‘In Progress’ or ‘On Hold’ states.  
  • User story ‘US7626’ (second chart) was analyzed, developed, peer reviewed and tested in a short span (~2 calendar days) but spent ~9 calendar days in user acceptance test (UAT) state. One reason for this could be that the user story was not in the priority list for the stakeholders to be released or the priority lowered after the work started. As an opportunity for continuous improvement, we can look at the option where there is an opportunity to reprioritize the user story before the team starts the work.  
  • User story ‘US7322’ (first chart) spent a lot of time (~25 calendar days) in ‘Requested’ state and then some time in ‘On Hold’ state (~12 calendar days).  As an opportunity for continuous improvement, we can work with stakeholders to make sure that we are getting the right requirements and acceptance criteria for the user story along with prioritization. The total cycle time for this user story could be also more because of the complexity and/or dependencies on the other integration deliverables. In either case, metrics shows the bottlenecks and provides an opportunity to optimize work flow for future such occurrences. 
  • Above metrics also gives the overall cycle time for different sized user stories and defects, which helps in predicting for future work and ability to give a better commitment for the stakeholders 

Summary
User Story is like a fish, the longer its sits on the shelf, the less desirable it becomes. Use relevant metrics to measure lead time in each of the Kanban columns (states), which helps to identify the bottlenecks and to improve planning and forecasting. 


I will be sharing case studies, process improvements and best practices specific for Kanban in my future posts. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com 

Metrics For Maximizing Productivity In Kanban SDLC was originally posted under Prokarma Blog on Sep 8th 2015

Tuesday, September 1, 2015

Kanban & DevOps - Forming a Perfect Alliance

Introduction 
"It is not the strongest of the species that will survive, or the most intelligent. It is the one most adaptable to change.” - Charles Darwin

As Organizations are going through a disruption phase including disruptive innovations with processes and technologies, there is wide adoption of Agile based transformation. In the context of the transformation, there is no better time of coming together of DevOps and Kanban, both of which enable Organizations to be more Agile in delivering services to their customers. 

What is Kanban?
Kanban is one of the lightweight Agile based methodology, which is based on Just-In-Time (JIT) software development. In Kanban based SDLC, the process from requirements of a task to its delivery to the customer, is visualized and team pulls work from a work item pool or queue. 
Kanban is based on simple 3 principles including
  • Visualize Work In Progress (WIP)
  • Limit the WIP
  • Maximize Productivity (by minimizing lead time)
Engineering team does not have time constraints in Kanban while focus is on making sure the work keeps flowing by limiting maximum number of features or issues, which can be worked on at a given time.

What is DevOps?
DevOps formulates collaboration of Operations and Engineering teams to achieve continuous delivery by participating together in the entire service delivery lifecycle.
While the Engineering team remains focused on
  • Analyzing,
  • Designing,
  • Coding 
  • Testing and
  • Production Support
of new services, the DevOps team combine together for
  • Release management,
  • Provisioning,
  • Configuration management,
  • Systems integration,
  • Monitoring & control and
  • Orchestration
of the new services

How Kanban & DevOps Match Perfectly?
Kanban and DevOps combine together to help bring down the silos between Engineering and Operations teams. Basic principles for Kanban and DevOps remain common in terms of
  • Collaboration,
  • Cooperation,
  • Communication, 
  • Integration and 
  • Automation
while bringing in transparency across the board. Managing a Kanban board provides the level of transparency in visualizing items in each of the work streams while formulating cooperation between teams by communicating dependencies, integration points and identifying items for automation.
A typical Kanban board could have items in following work streams
  • Analysis
  • Design
  • Coding
  • Testing
  • Operations (Automation, Integration, etc.) and
  • Production Support 
providing the visibility on high priority or expedite items while also sharing the respective status of to do, in progress or done items.  DevOps with Kanban maximizes the productivity with efficient delivery by 
  • Reducing the overall cycle time of delivering services to end user 
  • Identifying bottlenecks with items that are taking a long time in a work stream 
  • Improved tracking of effort and associated costs
  • Identifying recurring work that can be automated 
  • Providing visibility to the end users of when services would be actually delivered 

Summarizing
Primary objective of Kanban is combining productivity with efficiency in developing services while primary objective of DevOps is to achieve continuous delivery by continuously integrating the services developed by the Engineering team and delivering those services with high quality. In summary, embracing Kanban and DevOps allow Organizations to introduce new services more often in a more stable environment. I would be sharing more information in next blog posts including best practices, tools and case studies corresponding to Kanban and DevOps. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com

Friday, December 5, 2014

20 Guidelines for a Productive Meeting

20 Guidelines for a Productive Meeting blog post originally appeared on Prokarma Blog

Sometime back Verizon commissioned the Meetings in America study to gain a better understanding of meeting trends and the needs of its customers. Study provides some very good insights on how meetings are perceived and includes interesting stats such as:
  • 91% of professionals admit to daydreaming in meetings, 
  • 95% say they miss either all or part of meetings, 
  • 75% say they bring other work to meetings and 
  • 39% say they have actually dozed off during a meeting
  • 92% on the positive side, value meetings as providing an opportunity to contribute, suggesting that successful meetings may be a contributing factor to employee job satisfaction.

Even though above study seems specific to United States, it applies globally as well. To have a productive meeting, consider the following guidelines.
  1. Define purpose of the meeting 
  2. Consider who needs to be invited
  3. Email goal(s) wise agenda well in advance
  4. Arrive 5 minutes early for the meeting 
  5. Start and end meeting on time
  6. Come prepared for the meeting especially if you are the host 
  7. Take notes or identify someone to take notes 
  8. Set expectations to switch off or keep smartphones on mute during the meeting
  9. Share all relevant data for the meeting ahead of time
  10. Be brief and concise during the course of the meeting 
  11. Encourage participants to share their thoughts without interruption 
  12. Encourage everyone to participate in the meeting
  13. Respect people’s thoughts so if needed, disagree without being disagreeable 
  14. Direct the conversations to encourage participants remain focused on topic(s)
  15. Silence is perceived as an agreement when an opinion is needed
  16. No side conversations or comments should be encouraged 
  17. Challenge ideas rather than people 
  18. Agree on actionable items before wrapping up the meeting
  19. Summarize main points discussed in the meeting and
  20. Follow up with an email including minutes of meeting