printf(“Hello World!”) Part 2

As our journey to the new product continues we are facing the typical challenges of phase 2 in the software development life cycle, the design phase (see part 1 for the overview of the phases):

 

Design and Components

The new tool will deal with Active Directory security so it has to integrate into large scale Windows based customer environments, which in turn makes the decision about the components quite easy ;-). We have chosen .NET as our primary development platform including key components from Microsoft to run our application, these components include the IIS and Microsoft SQL Express/Server and of course one Windows Server.

The IIS will run the user interface to avoid any additional software on the client side and to keep the footprint and also the access vector small and easy. Choosing web technologies might raise a lot of discussions anyway – one example: We tried to avoid any kind of additional technology/frameworks, because every single framework

• must be tracked for vulnerabilities and patches
• requires then extensive test cycles of patched versions
• and maybe adjustments within the code base to address compatibility issues

just to name a few and there is still no good software for automation of this task available (remark to myself: maybe something for another ERNW SecTools product). Not too surprisingly we ended up with some compromise, because proper usability was also one of our design goals beside security. But this is real life when developing (secure) software and can serve as an example how to deal with it: We discuss every feature in our regular jour-fix with a specific agenda:

• Is this feature required for functional purposes?
• Is this feature required for usability purposes?
• Does the feature introduce new security issues?
• What kind of impact do they have?
• Can these newly introduced security issues be addressed?
• What are the costs?
• Are there other options?

Running through this agenda helps us to make reasonable decisions regarding the implementation of the new feature.

Privileges

Another important topic to deal with are privileges. And sometimes the need to think about privileges is not quite obvious, e.g. installing updates via the web user interface. The service account running the IIS needs privileges to install updates and replace corresponding files, but no one seriously wants to give a web server process the rights to replace binary files on a server, right ;-)?

Windows supports impersonation, which means that the web server can switch its identity to a higher privileged user, install the update and switch back to the low privileged service account which is used for running the web server. This doesn’t mitigate the risk completely, but it reduces the attack surface significantly – a nice example for the principle of least privilege (btw, our old friend Dominick Baier has a nice blog discussing Identity & Access Control, and a Twitter account under this name).

Besides this we also designed privileges within the application based on roles and sets of user rights (some rights don’t make sense, if used without another one) to reduce complexity and avoid human errors when setting privileges. Discussing the privileges and sometimes the corresponding edge cases also helps to find out if certain functions are really required.

Based on all these discussions we make decisions about the design of our tool and we try to use our experience regarding security, development and operating of applications. This doesn’t mean that everything is perfect, sometimes there are trade offs between functionality and security (but we are aware of those and accepted the residual risks) and there are still a lot of things that can go wrong when implementing all that stuff. But this is another story that will be told in one of the next parts ;-). So if you are curious, stay tuned and follow our blog posts regarding the development of the tool.

Cheers
Michael