安全损害给企业带来的消极影响巨大且深远。例如，企业有可能会消耗大量的时间和努力来修复系统、打官司及恢复声誉等。在涉及到安全问题时，企业需要做的功课还很多。

　　许多IT的决策者倾向于将其安全工作的重点几乎完全放在了网络外围。他们忽视了每天都在运行着其日常业务的应用程序，这些操作可以使客户和厂商与内部系统发生交互。这些应用程序往往与信用卡、个人身份信息等有密切的关联，容易被攻击者利用。

　　但仅仅重视基础架构和应用程序级的安全功能是不够的。企业还必须考虑其设计和实施中的缺陷。搜索企业应用程序内部的安全缺陷的黑客常常能够发现这些缺陷，因而能够不受限制地访问硬件、操作系统和应用程序与其进行交互的数据。事实上，多数安全损害都是由应用程序造成的。

　　企业等待解决安全问题的时间越长，其代价就越高昂。因为每个应用程序都可能包含安全缺陷，因而尽早地确认和减轻这些缺陷可以为企业节省大量的金钱。所以，不应当忽视或拖延应用程序的安全问题。

　　有些公司也能够理解应用程序的安全风险，并且为使风险最小化还分配了责任。建立首席信息安全官（CISO）这个角色的目的就是如此。企业应当为每个应用程序的开发小组都指派一个安全专家，确保所有的开发者都可以轻易地访问应用程序的安全问题的解决方法，这应当成为一种常识和惯例。

　　然而，确认安全漏洞的方法有着很大的不同。例如，在渗透测试中，软件从网络的外部模仿黑客的行为，而且这种测试还可以由"白帽"黑客手工突破应用程序的安全性，对软件测试起到补充作用。很不幸的是，渗透测试的效用是很有限的。在测试结束时，它只能发现问题，并不是解决问题，而且也不能保证发现所有潜在的问题。所以国外有人将"渗透测试"戏称为"恶劣状态指示器".

　　还有些企业通过Web应用程序防火墙来解决应用程序的安全问题。这种设备可以监视进出应用程序的通信，进而分析并阻止通信中的异常。这种技术在实际使用时可能会面临困难，因为所发现的异常模式有可能实际上是合法通信。

　　为保证数据的安全，健全的方法必须能够检查应用程序的内部运作，能够发现产生安全漏洞的代码在哪一行。该方法需要在代码级别上解决这些漏洞。最后，该方法必须用一种全面的防御策略来应对风险因素。

　　作为一位首席信息安全官，应当采取哪些措施来避免安全危害呢？[page]
　　一、发现并评估潜在的漏洞

　　1、对所有的应用程序实施风险管理方法

　　对所有企业来说，这个阶段的首要一步是部署一种能够创建每个应用程序的最新特征（这包括版本号、更新、补丁、当前配置等）的资产管理系统。这种信息可以与已知的漏洞建立关联，并可以跟踪必要的更改。这种信息还支持应用程序的风险等级排队，并且为保护应用程序的安全，还需要确定为此付出的努力的优先顺序。

　　2、确认与某个特定应用程序进行交互的所有应用软件进程。

　　检查端到端的应用程序的数据流，确认每个应用程序与其它应用程序、硬件或数据发生交互的点。这些点最有可能成为攻击者的目标。必须注意，应用程序组件，如web2.0组件、面向服务的架构、开源库、老系统等都常常用于新开发的应用程序内部，并有可能成为数据流的一部分。知道这些组件在哪里，并知道每个组件中会发生什么，就可以更轻松地分析数据和操作通过的路径。

　　3、区分漏洞的优先顺序

　　上述步骤会产生一个需要解决的多种漏洞的清单。不要从小漏洞开始，应当优先考虑对企业运营和战略最有可能产生潜在影响的漏洞。虽然你可以也应当使用这个漏洞清单作为下一步的行动指南，但这些漏洞仅仅代表许多企业需要马上就解决的一部分问题。系统性的问题来自于开发过程。许多正在使用中的老应用程序常常易于遭受攻击。

　　二、培养风险意识和解决问题

　　1、向相关人员发出风险警告及补救的需要

　　仅仅告知相关人员：应用程序的安全是整个信息安全的一个关键组成部分，这是远远不够的。他们需要理解不安全的应用程序威胁企业的特定方面及其潜在后果：损害客户信息、违规、丢失客户、影响销售等。安全专业人员要教育IT人员，特别是要教育应用程序的所有开发者，发现并解决安全漏洞。

　　2、教育开发人员

　　修复错误的最佳方法是一开始就不犯错误。不幸的是，多数培训机构（包括大学）都没有教育程序员如何安全地编程。用高效的教育方法，向软件的开发人员展示其代码中的漏洞，就可以强调在开发周期的多个时点上审计和测试源代码的重要性。

　　3、强化内部人员的安全意识

　　企业可使用海报、T恤衫、重要会议等方式来强化安全意识，要求开发人员的安全培训能够传递保障应用程序安全的概念和重要性。在安全有重要影响的企业中，安全也是绩效评估过程的一部分。[page]
　　三、创建并部署、配置应用程序安全功能

　　1、制定保障应用程序环境安全的要求

　　企业必须从明确定义的要求开始。每一个应用程序以及应用程序环境都要作为一个整体，必须包含能够将预防、检测和纠正问题作为一个安全整体的特性，必须包含防止安全损害的能力，必须在用户无法防止时能够检测安全损害，并能够补救由于未检测到的威胁所造成的任何损害。

　　2、为应用程序制定多层安全访问控制机制

　　当今的应用程序不能仅靠口令来保障其安全。新的认证方法可以使公司领先于黑客社团的有组织犯罪，而深度防御是应对日渐猖獗的间谍软件一种好方法。关于深度防御，本人在日后的文章中将深入阐述。

　　3、将防止、检测、修复安全损害的功能纳入到已经购买的、外包的、内建的或其它来源的应用程序中

　　首先，购买的应用程序往往包含自己的防御和检测功能，却很少包括修复和恢复功能。应向开发人员或厂商要求已知漏洞的补丁，并要知道已经应用了哪些安全补丁。在签订任何合同之前，要求加入一条必须对任何确认的漏洞立即打补丁的条款，还要规定相应的违约责任。

　　其次，外包的应用程序通常也包含安全功能，但未必满足公司的所有需求。你必须批判地分析这些功能，并用内部开发的方案或插件来补充。对于已经为公司定制的外包应用程序，你必须确保该程序能够与客户端身份管理系统或其它访问控制机制相集成。

　　第三，内部开发的应用程序必须根据已经认可的可用组件并包含防御、检测、纠正等功能。所有的内部开发人员必须对每一个应用程序使用同样的安全组件，以确保连续性并使创建的代码数量最少化。必须在多个时点上在多个应用程序之间测试这些可用组件，以确保跨应用程序的安全性。

　　第四，开源软件必须与内建软件一样遵循同样的规则，内部的开发人员要能够影响可用组件的创建和可用性。开发人员最好是开源社区的一部分，只有这样他们才能参与到确认安全问题并针对漏洞打补丁的过程中。

　　4、在打补丁或编码后，要测试修复程序，以确保该过程能够解决漏洞及其根源。

　　在应用了补丁后，要执行压力测试，检查整个系统的安全性而不仅仅是检查补丁是否正常工作。例如，假设你的登录功能有一个漏洞，其中的系统能够将口令中的星号（*）当作是一个通配符，从而可以使任何人都可以访问系统。在常规测试中，开发人员要增加一个补丁程序，用星号测试大量的口令，确保系统不会将星号当作通配符，然后再把打了补丁的软件投入到实际的工作（生产）环境中。而在压力测试中，开发人员必须测试每一类用户名和口令，确保系统不会将某个其它符号当作一个通配符。[page]
　　四、制定连续性的方法，以发现并评估漏洞

　　1、使用厂商的警告和公共的漏洞数据库，以跟踪新出现的应用程序安全问题，并长期且连续地评估漏洞。

　　企业不妨考虑构建一种职责来跟踪已知的问题，用以防止遗漏安全检查的工作岗位。该角色还可以监视常规的漏洞评估。保持应用程序的安全并不是一个一次性的过程，虽然它要求与最初发现漏洞一样的检查。必须经常地对照标准检查安全问题，查找任何异常情况。

　　2、对环境中的每一次更改都要扫描并测试应用程序的安全性。

　　要针对所有的已知漏洞扫描所有的新代码，在每一次部署中，对于新确认的漏洞也要扫描所有的老代码。要记录、跟踪以前的软件漏洞，并确保将来不会犯同样的错误。如果你的应用程序环境并未发生任何变化，尽量保持与厂商的警告和新安全威胁的同步也就足够了。当然，由于安全扫描和测试自身也会发生变化，你还需要监视新出现的问题，以决定是否采用新的测试过程。否则，就要在每次变更时测试应用程序的安全性，并至少运行一次测试，以捕捉任何意外的、及授权的变更。

　　3、向开发人员提供一套可靠的程序，使其在应用程序的编译和部署之前、在投入生产中之后都能够扫描代码中的漏洞。

　　静态分析产品在开发过程中变得日益普遍。但是，要理解对质量和安全的静态分析需要采取不同的方法，这很重要。质量的静态分析受到能够理解漏洞的开发人员的广泛认同。而安全的静态分析，常常要求安全专家具备一套健全的"安全思想和理念".

　　五、在应用程序的整个开发周期都要保障应用程序安全

　　1、要为安全架构和应用程序的安全设计确立责任和义务

　　安全的开发周期，在保证跟踪并强化开发过程的任何时期，都要建议一套特定的检查和活动，确保开发团队产出代码的安全性。例如，在设计阶段，安全的开发周期将会建议安全团队进行架构检查，验证是否解决了安全问题。

　　2、提供与现有的IT工具和程序相集成的修复功能

　　由于时间在安全问题上至关重要，所以任何应用程序的安全解决方案都应当包含这种工具：能够在安全人员、开发人员、重要业务的关系人等方面促进团队工作。与现有的程序相集成，如与漏洞跟踪系统或开发环境的集成，可以改善通信，并可以提高对新威胁的响应速度。[page]
　　3、将多种漏洞检测方法整合到一个健全的控制点上

　　应用程序的安全解决方案必须从应用程序的内部出发，能够在多个点上捕获数据，实现更全面的漏洞检查。这可以使IT人员寻找能够指明哪些漏洞需要优先解决的模式。只有应用程序安全的测试方案同时包含静态分析和动态分析，才可以检测最大范围和数量的安全漏洞。静态的分析，可以在编码的过程中实现，它可以自动检查应用程序的源代码，并向应用程序的开发人员发出漏洞警告。而动态分析则是在测试和生产阶段的应用程序内部进行，其目的是为了查找仅在执行代码时才可能表现明显的安全问题。

　　4、在软件通过完全的测试之前，禁止其进入生产环境。

　　在没有针对当前的已知威胁进行测试之前，不要将应用程序投入使用。在系统开发周期中，应当对任何代码的变更都实施此要求。

　　六、将应用程序的安全作为日常运维的一个不可分割的组成部分

　　高效的应用程序安全策略要能够解决紧急的和系统性的风险。多数企业使用的应用程序的范围都很广，这包括外包的和现货供应的应用程序、开源的及内部开发的应用程序，每一种程序都有其发现并修复安全漏洞的不同方法。然而，多数软件开发者并非安全专家，而多数安全专家也不开发软件。要让一个IT团队有那么即使一两个在安全和开发两方面都精通的"通才"也几乎是不可能的。将应用程序的安全问题完全交给内部解决，就如同要求招聘特殊技术人才一样困难，或者就像通过培训现有的雇员来构建这种技术一样不太可能。这两种选择都极其昂贵并会消耗大量的时间。

　　应用程序的安全保障是一个系统工程，是应对应用程序的风险问题的不同人员、过程、技术等的综合体。应用程序的安全保障有三个不同的要素：在现有应用程序中能够衡量风险的减少数量， 防止新风险的引入，确保与应用程序的安全要求保持一致。

　　企业可选择的一种解决方案是，与一个在安全和开发方面都擅长的厂商合作。这个解决方案应当扫描现有应用程序中的漏洞，并告诉开发人员如何修复这些漏洞。还要确保在每个阶段（从设计到代码编写，再到测试和实施阶段）的代码安全性。这不但能够解决评估和修复安全风险的问题，还可以解决系统化的问题。实际上，多数软件开发从一开始就没有将安全性整合到编码和测试过程中。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。