One of the most important and often most evasive security measures which can be employed in an area is in the design of new services. All too often, little regard is given to how securely an application, website, portal, or system is initially implemented. A significant regard for security is crucial at this stage. In this stage, many decisions may be made with regards to the implementation which cannot be altered for the life of the service. A department would then be forced to instead try and build security *around* the offending service, in hopes that most risk can be mitigated. This often can prove to be much more costly both in time and money than simply designing an service correctly from the get-go. It should also be mentioned that these questions are crucial not only if you are implementing something yourself, but also if a consultant is on board to perform some or all of the work for you.

What platform will you select?

There are many technologies to chose from these days. There exist scores of different programing languages, operating systems, proprietary off-the-shelf (OTS) software packages, protocols, transport mechanisms, and databases, just to name a few technologies! All of them often completely interchangeable in operation, but also completely different in security. The potential questions which can be asked are numerous. How familiar are you familiar with a particular technology? Is there widespread support for that technology's security? Has the vendor representing that product been proactive towards security in the past? How easily maintained is the technology? Are there other experts locally you could tap on the shoulder when you need help with the technology? Is the technology well established, or has a sizable user-base? Is this technology being considered only because of legacy applications, or has it truly started to fall by the wayside in modern operation? All these questions should be considered as a whole. How much slack you're willing to give towards answering these questions should directly reflect the kind of risks you are able to afford when the services goes live.

Are you developing a full blown application? Or just a website?

Trick question! Both should be treated the same way. Either the most complex, low level C application or high level web-app could both easily offer vectors for abuse. Fortunately, for most established technologies there exist large communities that try to help individuals make the right design decisions and avoid common or even little-known pitfalls. There also exist a great many books on the subject of writing secure code and applications. Often this may be a very inexpensive alternative to re-engineering a problem later. Here are a few examples, but please do not hesitate to contact us if you think something should be added!

OWASP: The Open Web Application Security Project. The bar in web security, and a fantastic resource. Their top-10 list is often referenced.
Sun Java Security and Security Guide : Sun Microsystems offers a wealth of knowledge on how to properly write secure java code -- an often underestimated feat. The abstraction java provides can often be a security pitfall.
OSVDB : The Open Source Vulnerability Database. This project details security vulnerabilities in an open source manner, but for all kinds of software -- not just open source but proprietary too! It can be an excellent reference guide for investigating a track record of a piece of software. There exist many other vulnerability databases such as the NIST sponsored one.
Microsoft : A widely recommended book for writing code on Microsoft Platforms

Will remote access be required?

More often than not, access to the service will be provided on a worldwide basis. This imparts significantly more risk, in so far that the potential for the application to be abused is horrifically greater if the entire world is invited to examine the front door. This decision should naturally impart a much greater monetary valuation of the risk imposed verses if access was given to just to RUNet, a particular subnet, or even a delineated list of IP addresses. Use of the University VPN can often allow the service to be restricted in where it is accessible from. Bear in mind that although a service may reduce its risk of exploitation if you limit who can access it, that does not make it secure by any means. An increasing number of attacks utilize already-compromised internal hosts to try and attack services which are limited in just this way. This kind of attack is often seen on networks as large as RUNet.

How will you resolve authentication?

Authentication is the process by which you verify the identity of a subject requesting the use of a resource. The front line of defense for almost any system or application is the authentication process. There are many solutions which can be employed to varying degrees of simplicity and/or security. While most out-of-the-box solutions can inherently provide both authentication, you may want to consider leveraging a variety of university resources instead. You may also chose to read our guide on password strength and theories [LINK PAGE].

Kerberos - Kerberos is a network authentication protocol. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business. The actual password, or even a hash for the password, is never transmitted over the wire.

LDAP - The Lightweight Directory Access Protocol is an application protocol for querying and modifying directory services running over TCP/IP. It can perform both authentication and authorization services.

RADIUS - RADIUS is an extremely lightweight authentication service which can be leveraged on a very wide number of platforms. It is often provided as a front-end for other kinds of authentication platforms like Safeword, LDAP, or Kerberos.

Safeword - Safeword is an example of a token technology. Tokens are small devices which allow an administrator to leverage two-factor authentication. The user enters a PIN on the card, known only to them, and a password which is good for only one use is displayed by the token. This is then used for authentication into the system. This is a good method to employ for services which must be very secure or if the network connection is in the clear.

Should encryption be used, or would it be unnecessary?

Long regarded as being in the same domain as tin-foil hats, encryption is now an essential technology in almost all network aware systems and applications. Many regulations and policies in fact require the use of encryption for things like database storage, network transmission, authentication, or interprocess communications. Rarely could encryption be regarded as completely unnecessary. It should always remain an option when detailing the cost-benefit analysis of a particular implementation.

How do you plan on documenting the work done?

Documented processes are inherently consistent and well planned. They enable a department to recover after a disaster, quickly examine a process for flaws, or readily provide an upgrade path. Unfortunately, they are often an anathema to most implementors. If a consultant or outside group is called in to perform work for your organization, it is especially important to request verbose documentation on the work done. All too often a consultant will be hired to do a terrific job of setting up a system or service, only to have it compromised a year later and leave a group high and dry when it comes to rebuilding it.