Category Archives: Software Engineering

Product Manager awareness about Secure Development

PProject Managers and Product Owners must be aware about Secure Development aspects on all Software Development Lifecycle (SDLC). This article shows the initial steps to add security aspects as part of the Product Manager responsabilities. The number of vulnerabilities and threats to software systems has exponencial increased [1]. Product management techniques need to be revised and the heads of product development must deal with security non-functional requirements as a new norm. The old fashion way was to delegate all security aspects to network management, however the modern threats use application layer as main point of failure and choices made on earlier vision of the product may cause profound damage to companies reputation. Independent where the application is deployed, if it is in the cloud or on-premises the secure development aspects changed and need to be addressed since the conception of the product.Other views like governance and intelligence is not covered in this article but are extremely valuable to PMs.

The following video[1] talks about the estimated cost of cybercrime in 2014, this will highlight the importance of the taking into account security non-functional requirements on Product Vision and Product Design phases.

 

Implementing security into software applications

SDLC models help software teams to define achievements and artifacts of each development phases, product manager should work to achieve understanding and formulate progress on security aspects for each SDLC phase. The objective in each SDLC phase from security point-of-view are:

  • Planning, Understand and document Legal and Customer Security Requirements, Compliance and Training. (e.g. SOX, PS-DSS, GLBA, HIPAA)
  • Design, Modeling Threats and define Secure Design Principles (Attack surface reduction, Least privilege, others…).
  • Construction, Integration validations, Code Analysis, Code Review. e.g. input validation, fault injection, penetration testing.
  • Deployment and Support, Plan for Incidents Responses, Patching and Recovery.

To support the guidelines recommended above is mandatory a software engineering practice and a security chapter to specify models, standards and guidelines to be followed.

Models

Microsoft SDL [3], a model to help software development teams to improve and sustain the security and quality aspects of software products. This model helps Product Managers with recommended security requirements, tools, testing and conducts, reviews and plans.

Standards:

PCI-DSS and PA-DSS [5], These are the Data Security Standards that are used in any financial application that contains transactions with credit card information.

…others, SOX, GLBA, HIPAA and others , but let me know (post a comment) if you want a deeper dive on this list.

Guidelines and Reports

Open Web Application Security Project (OWASP) Top 10 [2], a guide that shows a list of the top 10 vulnerabilities of Web Applications, as well as how to recognize and mitigate the risks. As a Product Manager you need to be aware of it and have to track from requirements to deployment if such top vulnerabilities are mitigated or not.

CWE/SANS Top 25 Most Dangerous Software Errors[4], a report issued in 2009,2010 and 2011 showing the prevention and remediation steps that Product Managers can take to mitigate software weakness. The funniest is that SQL injections is still a threat nowadays.

Continuous Updates

All information provided in the post was compiled in December 2018. Be aware that Hacker methods are constantly evolving, as are the security techniques to address them.

Keep your self updated with the last updates on the security models, standards, and guidelines to improve your application response to threats and vulnerabilities.

For instance, OWASP [2] publish new versions annually.

References:

  • [1] https://www.csis.org/events/2014-mcafee-report-global-cost-cybercrime
  • [2] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
  • [3] https://www.microsoft.com/en-us/sdl
  • [4] http://cwe.mitre.org/top25/
  • [5] https://www.pcisecuritystandards.org/document_library

 

Updates:

Dec 2017, Initial Version

 

If you liked this post and want a updated version, send me a message on LinkedIn or @GorskiRafael.

Developers Challenges on Requirements and Documentation

II will be talking about how software requirements are important for developers. Here I put software requirements in a agnostic project methodology ( Agile, Waterfall, or V-Model) view. If you are a developer or manager, for sure you have hear the following statement:

” Our project documentation is poor, it is complicated to understand the requirements.”

Couple months ago I hear this, and I talked to the team to align what was the problem, in this case was an expectation regarding the level of the detail inside a specification. Which we solve by increasing the verbose on the tasks (User Stories, if you prefer.). So this one was easy for the analysts (P.O.). But to take action to solve it by getting this from a retrospective or a water-cooler talk is the key.

Listen and understand the development team is not easy task when mix different cultures, styles, and personal expectations. So take time to put things on track. But worth it!

I read the Stackoverflow 2016 software development survey and the same complain shows up. Well it is more common than I thought. It is quite obvious, however from the numbers there are a significant quantity of developers complaining about documentation and requirements.

Over 75.000 devs (0.4% of overall users of stackoverflow) de 20 a 34 years in USA and Europe classified challenge the following three things:

  • Poor Documentation
  • Unspecific Requirements
  • Changing Requirements

To enrich this discussion and see it in another point of view I will describe below the strategy how to identify the problems related to this context using the PBSRS method. It will give you an example of directives of how to deal with this scenario.

First Step, Analyzing the Context

The context depends on several attributes[2]  and your company context is different from mine. Thus I will propose a hypothetical context that is familiar to me. I recommend to see the Kruchten (2007) work to map your context.

My hypothetical context here is:

“A company has a strong difficulties to effectively specify the requirements for the software development team. Developers complain about poor documentation, unspecific requirements, and changing requirements.”

Step two, Define the Mitigation Actions or Customer-Problems

From this context we can translate the following actions to mitigate or try to mitigate the problems statements:

  1. The Software Development Manager must ensure the existence of software requirements specifications available for Developers , otherwise excessive learning-curve will be generated and extra rework may apply.
  2. TBD (Other action problems can be derived here.)

Step-three, Define the Software Needs

(TBW, I will write this part in my next time.)

Step-four, Define the Software Requirements

(TBW, I will write this part in my next time.)

Terms

ReqDev – As manager can we build a Req-Dev approach? It is a analogy to DevOps movement that clear recognize the need of developers and operation work together to increase value and streamline the processes in contrast of push and pull mode.

 

References

[1] http://stackoverflow.com/research/developer-survey-2016

[2] Kruchten, Philippe. “Voyage in the agile memeplex.” Queue 5.5 (2007): 1. Available in: 10.1145/1281881.1281893

[3] Problem Based SRS, Souza, Rafael Gorski M., and Paulo Cézar Stadzisz. “PROBLEM-BASED SOFTWARE REQUIREMENTS SPECIFICATION.” Revista Electronica de Sistemas de Informaçao 15.2 (2016): 1.