From a non-security perspective, I would say, most management approaches and project budgets, are focused on the reactive. IT has historically, not always been seen as an efficiency provider for the business, with budget often only being assigned, when it's acknowledged that the business front line would be negatively impacted if a system, project or team would were not present. From a security perspective, I think reactionary policy is still deep in the mindset too.
When you casually think of information security tools and products, how many are naturally related to post incident or reacting? Security Information and Event Management (SIEM) and logging tools are generally post-incident, as if the event has been logged it's surely already occurred. File Integrity Monitoring (FIM) another post-incident approach. Anti-virus and anti-malware software, could arguably be reactive, as you are checking signatures for a known attack, indicating the software has already been spotted if an alert is triggered. The flip side to something like anti-virus, is that although something malicious has been spotted, you are preventing the real impact, which would occur if the malware were left to spread. Identity and Access Management (IAM) could be deemed to purely proactive however, as the process is attempting to restrict access before an issue could occur, either through malicious or non-malicious means.
Ethical hacking and penetration testing is another more proactive industry, but often, these services are not engaged until after an organisation or application has been attacked and breached previously. Budget release, especially for cyber security related technologies, is often easier, after an organisation has been attacked.
Moving to Proactive
Security has several issues from a proactive implementation perspective. Like anything, a detailed return on investment, including both tangible and non-tangible benefits, is required in order to sanction a project which wont necessarily deliver something immediately. Proactive security is more of a mindset and long term strategy, which can often be hindered if an organisation is then attacked after implementing a more proactive approach.
The implicit embedding of security in all software, projects and processes is often key to shifting to a more proactive standpoint. This can be difficult at several levels. Developers operating in the software development life cycle, are often more focused on time to delivery and software quality, with approaches such as Agile and eXtreme Programming (XP) not necessarily making security a high priority. Security can often be seen to slow down the development process and take attention away from use cases the client wants completing.
From a business process perspective, security can often be seen as inhibitive or restrictive. Again, time is a factor, but also, non-technical personnel are quite rightly more focused on their individual business use cases: delivering products, realising revenue opportunities and keeping customers happy. Unless, security is silently embedded into a process, it too can be see as time consuming and non-essential. Until, of course, a breach of attack occurs.
Security awareness is often a key part of the progress towards a more proactive approach. Awareness not only at every day non-technical personnel, via regular on line training and workshops, but also at the board level too. Security metrics can be used to help promote the idea that security up front is often more cost effective and business efficient than spending thousands on post-incident consultancy and investigative products.