So a few of you may have heard of NIST, the National Institute of Standards and Technology. I bet most of you haven't. You should know how they are if you care about cyber security, though, especially their 800 series of special publications (colloquially known as NIST SP800). They provide guidance for lots of cyber security concerns, and are supposed to be followed by United States civilian government agencies. If they were, we wouldn't have the problems we've had over the last few years.
NIST has the special publications series and the Federal Information Processing Standards (FIPS) series. They also have a specific process for identifying and deploying cyber security controls that anybody can use. It's a little extensive, but as far as giving you a starting point for identifying what you need to implement from a cyber security perspective, it's great.
In civilian government agencies, organizations are expected to use some combination of Federal Information Processing Standards (FIPS) 199 and 200 in tandem with NIST Special Publication 800-53 (SP800-53) to determine the level of cyber-security needed for deployed systems, and NIST Special Publications 800-160, 800-53A, and 800-137 to implement, assess, and monitor security controls. The first two publications establish the security needed by the system based on the information managed and the potential impact of an information leak. They guide readers through a process through which they inventory any sensitive data managed from a confidentiality, integrity, and availability perspective and determine whether the risk of compromise is low, moderate, or high. This determines a security triple for the system. Once this triple has been established, system managers classify the system as a whole at the highest level of risk from the triple. For example, a system with a triple of (confidentiality: moderate, integrity: moderate, availability: high) would be classified at a high level of sensitivity. Once the baseline sensitivity is in place, system managers use SP800-53 to select system security controls. These controls are divided into just over 20 different families, each of which contains some number of individual controls. Engineers then select controls to deploy based on the sensitivity assessment of the system, where systems with higher sensitivity require a higher number of more invasive controls than systems with low sensitivity. Once the controls are selected, implementers map them to specific instantiations that can be deployed within a given system. Once deployed, the controls are regularly assessed for operational effectiveness and monitored to ensure both correct operation and correct system state.
This seems pretty dry, and the list of possible controls excessive. Don't let that throw you, though. Personally, I've used this process in lots of different situations, from evaluating WANs and LANs to software libraries. The key thing to realize is that the list of possible controls is so large to accommodate the different environments you might deploy in, and that not all controls apply to every situation. Many of the administrative controls, for example, are important when doing large scale network analysis, but have no real bearing on setting controls for a group of DLLs. Other controls, like penetration testing, apply almost universally.
This isn't sufficient to develop secure systems, but it's a necessary first step, and it doesn't take as long as you'd think. Give it a try on your next project—you won't be disappointed.