Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
Whether your development team is using the Waterfall, Agile or iterative model, every piece of software that you release usually goes through a development model, or Software Development Life Cycle (SDLC), which includes a chain of activities that ultimately lead to a software release.
A classic SDLC would include several phases: requirements, design, coding (also called implementation), testing, deployment and maintenance. Deployment covers the final release of the software (like for example the release of a Minimum Viable Product), maintenance and testing cover bug busting after your software has been released and as it is being developed (respectively). Coding and designing involves building the structure of your software, while the requirements phase tells your development team what they should be building in the first place and how.
At Advantio, we like to refer to the SSDLC, or the Secure Software Development Lifecycle, hence a securely implemented version of a standard software development model. We will try to cover a few aspects of the SSDLC in this article, mainly concerning its requirements gathering phase.
The requirements phase is where you decide upon the foundations of your software. It tells your development team what they need to be doing and without this, they would be unable to do their jobs at all.
The list of 'requirements' of your software should address who your customers will be and what needs of theirs your software is able to address. For example, which demographics do they fall into; are they old or young, what's their gender, what do they already know and what are the issues that they face in their day to day life? You also need to know how they'll be using your software, what sort of information they need to put into it, as well as the outcomes they'll get from your software.
Once the list of requirements has been put together, the team will need to finalise and approve them, analysing each and every one on its ROI (Return On Investment) and whether it provides the user with genuine value or not. Following this, the list can be sent off to the design team who can put together their own specifications ahead of the coding work in SDLC phase three.
The participants of the requirement phase will vary from company to company; each one will have a different hierarchy including people of varying levels of knowledge. But as a general rule of thumb, the requirements phase should include everyone with a solid knowledge of how to cater to the needs of the customer, along with everyone who is involved in making key business decisions.
For example, the CFO (Chief Financial Officer) is a beneficial feature at requirements phase meetings as they will be able to figure out just how much development is going to cost. They can use their understanding of the company's financials to suggest which features are going to be the most lucrative, which are going to need a significant investment to implement and what the company's stakeholders have said that they require from the software too.
Meanwhile the CTO (Chief Technology Officer) or the IT Manager will need to step in and explain exactly what they need from the software, technology-wise. This may include detailing the limitations of the hardware that the software is limited on and figuring out which of the requirements detailed by other team members will be possible within the realm of the technical specifications. They may even have extra requirements that are necessary in order for the software to run smoothly on the hardware as well.
Furthermore, those who have direct contact with your customers must also be included, e.g Community Managers. These people have their finger right on the pulse and know exactly what your customers want as they interact with them daily.
While software requirements are sure to make your software appeal to the customers (and indeed, appease the stakeholders too), this matters very little if your software isn't secure. Proper software security should be considered right from the very beginning; to ensure that your software's foundations are made of sturdy bedrock, not unstable bricks and sand.
Security can be considered during the requirements phase with something we call the 'Secure Software Requirements'. The Secure Software Development Life Cycle Requirements phase takes into account the resiliency, the reliability and the recoverability of your software. Is your software resilient from attacks? Is your software reliable when it’s under attack? And can your software recover quickly from even the most advanced attacks? These questions require attention and experience, this is why a security expert is a key role during the requirements phase of your SSDLC project.
We here at Advantio understand that your development team may not have implemented Secure Software Requirements before which is why we offer several different methods for making your software more secure.
We can review your software's code for you, we can evaluate the Software Development Lifecycle to ensure that your team is taking the right steps towards secure software and we can also train your team so that they have a better understanding of Secure SDLC (SSDLC) concepts and practices.
I have taken part to a few discussions about software requirements during my career and I find it extremely important to involve all the possible roles in this stage of the project. Unexpected input and a 360 degrees view can be achieved only when all the points of view and opinions are shared. The content of this article is based on personal experience, observation of the field and ultimately industry validated resources.
Column Header Text | Column Header Text | Column Header Text |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
|
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Performing a review of the media inventories at least annually |
Performing a review of the media inventories at least annually |
Performing a review of the media inventories at least annually |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
I am the CTO, Senior Security Consultant, and PCI QSA since 2010 at Advantio.
Having executed close to a hundred (and counting) assessments across Europe, Asia, South Africa, and North America, I was able to observe many different implementations of all classic security controls and much more.
Now I spend much of my time with cloud technologies. Being passionate about cloud security and cloud resources management, my research focuses on the implementation of streamlined and scalable processes in the field of Threat Management for cloud-based ecosystems.
At Advantio, I am also part of the ZeroRisk team. Our vision is to make security and compliance simpler for our users.
Comments