Badieh
Hello Everyone,
It's been a while since I've been in here, busy with watching real life fly by so fast hehe. Anyways, my question is addressed to the people working in one of the two fields QA/QC and IT security within a reputable company.
My question basically, do the people in the IT security have the privilege to test the applications for bugs, and ask access to the database to check if the application is working as intended?
The reason im asking this, is because I currently work as Head of Software Quality Assurance and Control in a bank, alternatively, the IT security keep asking to test the applications, we develop, before releasing them. Now, here is the catch, they don't use any tools or even check for security vulnerabilities, but instead, they tend to check for bugs, and whether the application works as requested by the business side. I find this to be highly inappropriate as they are doing the QA's job without knowing. They even had the gut to ask for source code at some point.
Is this normal? Should I try to put a stop to this intrusion? Are they really doing their jobs or just wasting our time? If not, how can I convince them otherwise?
Thanks!
elserge82
I'm sure you're not happy about it. But we as IT sec can ask for such things depending on the scope we have in mind it can be very technical (as in your case) or not ( working on policies)
IT sec usually have 3 controls in mind > Confidentiality Integrity availability.
Badieh
Thanks for your reply.
So you believe that the IT security department should test for those 3 elements themselves, instead of placing some standards that we, the QA, must make sure it is upheld by the development team?
crazy
Hi Badieh,
I completely understand your frustration as I see it everyday. IT security people are often seen as an obstacle, and instead of working with us, they find ways to circumvent us... (I've actually read internal documentation in one company I worked with on how to hide stuff from the IT security team...).
To answer your question, it is one of the IT security team's objective to protect the information of the company (in your case, the bank), and as elserge82 was saying, when we do a risk assessment on a new project to define security controls, we have in mind:
- the confidentiality of the information (access control, data encryption at rest and in transit, segregation of environments, security matrix, etc)
- the integrity of the information, making sure the data is not tampered with
- the availability of the information, making sure the data is available when needed
There are also other categories we look at, like business continuity and more.
Sometimes you get to have a security team involved because you have some standards or regulations the company has to abide by them, and others (that's the best one) when upper management actually understand the risks and fully supports implementing security controls/policies/process/directives etc.
To come back to your problem, and I'll try to be brief (as you can see I can go on and on about that topic), I personally think that the security team must help you introduce security in your SDLC (software developing lifecycle), that way they would not only help you secure the applications you are developing, they would help themselves because 1, they would be creating awareness about security issues, 2, they would have more time to focus on other stuff. On the other hand, don't think that if you have a secure SDLC in place you won't get code reviewed from time to time, or a pentest realized on the app, a control must remain in place to test the S-SDLC.
Lastly, I would add that a QA job is to make sure the application does what it's supposed to do functionally. The security team's job is to try and break the application whether using known exploits, sql injections, traffic sniffing if the data communication is not encrypted, or any other method to make sure that the data is as secure as it has to. So your jobs actually complements each other, but you need to work as a team and not in silos.
For some reference, you can easily find a lot of material on secure sdlc with a simple google seach, OWASP is a good source and many others.
Hope that helped!
elserge82
crazy wroteHi Badieh,
I completely understand your frustration as I see it everyday. IT security people are often seen as an obstacle, and instead of working with us, they find ways to circumvent us... (I've actually read internal documentation in one company I worked with on how to hide stuff from the IT security team...).
To answer your question, it is one of the IT security team's objective to protect the information of the company (in your case, the bank), and as elserge82 was saying, when we do a risk assessment on a new project to define security controls, we have in mind:
- the confidentiality of the information (access control, data encryption at rest and in transit, segregation of environments, security matrix, etc)
- the integrity of the information, making sure the data is not tampered with
- the availability of the information, making sure the data is available when needed
There are also other categories we look at, like business continuity and more.
Sometimes you get to have a security team involved because you have some standards or regulations the company has to abide by them, and others (that's the best one) when upper management actually understand the risks and fully supports implementing security controls/policies/process/directives etc.
To come back to your problem, and I'll try to be brief (as you can see I can go on and on about that topic), I personally think that the security team must help you introduce security in your SDLC (software developing lifecycle), that way they would not only help you secure the applications you are developing, they would help themselves because 1, they would be creating awareness about security issues, 2, they would have more time to focus on other stuff. On the other hand, don't think that if you have a secure SDLC in place you won't get code reviewed from time to time, or a pentest realized on the app, a control must remain in place to test the S-SDLC.
Lastly, I would add that a QA job is to make sure the application does what it's supposed to do functionally. The security team's job is to try and break the application whether using known exploits, sql injections, traffic sniffing if the data communication is not encrypted, or any other method to make sure that the data is as secure as it has to. So your jobs actually complements each other, but you need to work as a team and not in silos.
For some reference, you can easily find a lot of material on secure sdlc with a simple google seach, OWASP is a good source and many others.
Hope that helped!
I tried to summarize but you've read my mind.
elserge82
Badieh wroteThanks for your reply.
So you believe that the IT security department should test for those 3 elements themselves, instead of placing some standards that we, the QA, must make sure it is upheld by the development team?
They should do all the stuff you mentioned above, the 3 elements, policies , standards and many more... detailed by Crazy and I'm sure Crazy tried to make things short.
Badieh
Thanks for your replies guys. Reading what you wrote, I can now go into a bit more details. Though please keep in mind I'm not arguing here, but instead just trying to understand where the line is drawn between QA/QC and Security department.
It is true that the QA's job is to make sure that the application does what it is supposed to do, but you forgot that we also have the QC on our side, and that is where the real testing takes place. Our job is to try to break the code, to test not only for the functional requirements, but also for the non-functional requirements, including any security standards.
Other than all the stuff I learned at the university, and years of experience as a programmer, I did attend an EC-Council Certified Secure Programmer (ECSP) course. So I understand what the OWASP top concerns are. Having said that, we mostly develop Windows Applications that run on an internal network. This limits a lot of the security concerns. Like for example, if you have a windows application form that inputs data, inserts them into a table, then prints a document. If the insert statements are all done using parameterized querying, a built-in error handling system to manage any error exceptions to avoid the errors exposing to the user, and all the fields are validated and verified before they are sent to the table.
What's exactly left for the security department to check within the developed application? Probably if we obfuscated our executable? or if anyone could sniff out some information from the internal network? But you see, they don't do that. All they ask for is to test the application, and what they do is just go through the full functional cycle, like any other QA/QC testing. No additions.
Also like to add that we develop all the applications in the same manner, the developers follow a set of coding standards, which i might add, also includes security, that I've placed for them.
So it feels like either I am doing something extra that I shouldn't be doing, or them not really doing their real job.
crazy
Hi Badieh,
If all they do is another pass at the functional tests, then yes there is no value added to it.
I don't know the reasons for why they ask to do it again (it would actually be interesting to know that), but from past experiences, I never re-do functional testing... I don't care about it to be honest. As long as my QA/QC team says we tested it, it works as intended and here are the results of the functional/non-functional tests, I'm fine with it.
In any new project, whether it's an app development or an implementation of some sort or even an integration with a cloud provider, the first few things I do are :
- Understand the business need
- Identify the data/infrastructure that will be used (and hope that there is some classification done on it)
- Do a risk assessment that will help me define risk scenarios based on the Confidentiality/Integrity/Availability criterias
- Define security controls that I will follow-up on during the architecture phase, RFP, design, implementation, go-live
In the security controls I would have an activity to make sure that all security test related are communicated with the QA/QC team, and in time they will be testing them (sometimes with my support if needed).
If it's a web development, I will have a control specifying the best practices for web development, and I would perform a targeted pentest on the application when it's in QA. I will have several controls concerning security, it could go easily around 50-100 and even more depending on the application, the data, the infrastructure, the client, etc.
So basically I would have a lot of job to do and no time to do functional testing that was already done.
What I think you need to do, is to sit down with the IT security manager and define a process that will help you streamline all the development process, because security must be included at the beginning, and at that point you can identify roles and responsibilities for each activities (maybe they want to do all the security and negative testing so they feel confident that it's secure, because don't forget, if ever you guys get a security breach, the security team will be responsible).
Most of the time, when you don't have a matrix defining roles and responsibilities, these kind of situations arise and lead to redundant work, or worse, work not done.
Hope my block of answer is helping you a bit!
Crazy