SoftwareSecurity2012/Group 5/Reflection

Teamwork

During the project we met up a few times to work together and discuss problems that might have occurred. Every time we met up we looked at the work that we had to do before that and divided the tasks among the group. The division of tasks was quite easy, we chose a points of work that needed to be done before the next meeting and divided it among the group on the basis of who preferred which task. We didn't have any problems as we all had different preferences.

The way we worked was as following. We first divided the tasks individually and had each person look at a certain requirement. After this we only looked at a task as a group, if the person looking at it seemed to have trouble with his task. The reason for choosing this way to look at the whole code, was dividing the work among the group members evenly and therefore reducing the overall work. If we all needed to look at the same then we wouldn't be able to do everything in the allowed time. In a different situation, where there would be more time, it would be better to put 2 people on the same code as 2 see more than 1 person can see.

Code scanning

As described earlier, we did not find the code scanning results very helpful to our goal of reviewing the authentication and cryptography of the application. Results did not include anything related to the authentication or cryptography, although it would be really hard to automate tests on that. We have tried to use several code scanners, but neither of them provided us with proper results.

Code review

Reviewing the code was not hard for most of the requirements, since they are described in some amount of detail. Some requirements did require more effort to verify than others, for example V2.1 required more work, as we had to look for all places that expose private pages and resources. V2.4 on the other hand was quite easy to verify, as we knew that the site is written in PHP and PHP always executes server side. After working hard for a few weeks we managed to go over all the requirements and managed to cast a verdict on all of them. There was even some time left over to re-review certain requirements and make sure that everything is documented correctly.

Some requirements were a bit cryptic, for example V7.2 ("Verify that all cryptographic modules fail securely", what 'cryptographic modules'?) is not clear in what it exactly means. (Erik: You could have asked me...)