应用系统安全规范制定建议.docx
《应用系统安全规范制定建议.docx》由会员分享，可在线阅读，更多相关《应用系统安全规范制定建议.docx（18页珍藏版）》请在冰豆网上搜索。
应用系统安全规范制定建议
应用系统安全规制定建议
应用系统安全是当前众多大型企业要重点关注的问题,但这块有好多工作要做,现状是现在很多做安全的人,不怎么太做开发,做开发的人懂安全的人又少之又少,这里我从应用系统安全,提出几点自己的建议,当然不足之处还请大家讨论和指正。
1应用系统安全类别划分
具体划分准则,需要根据自己单位实际规模和业务特征去定位,我这里把具体的分类细则隐去了,有兴趣的可以讨论.
2.1网络安全性
2.1.1网络接入控制
未经批准严禁通过线、各类专线接到外网；如确有需求，必须申请备案后先进行与网完全隔离，才可以实施。
2.1.2网络安全域隔离
如果有需要与公司外部通讯的服务器，应在保证自身安全的情况下放入公司防火墙DMZ区，该应用服务器与公司部系统通讯时，应采用部读取数据的方式。
其他类应用系统服务器放置在公司部网中。
2.2系统平台安全性
2.2.1病毒对系统的威胁
各应用系统WINDOWS平台应关闭掉服务器的完全共享，并安装防毒客户端软件，启用实时防护与接受管理，进行周期性对系统全机病毒扫描。
2.2.2黑客破坏和侵入
对各应用系统应及时进行系统补丁的升级和安全配置，并配合进行入侵检测和漏洞扫描等安全检查工作。
对于重点系统可以考虑部署主机入侵检测系统来保证主机的安全性。
2.3应用程序安全性
2.3.1在应用系统的生命周期中保证安全
应用系统的设计和管理者要在不同的阶段采用相应的工作方法和工作步骤，设计出一个把安全贯穿始终、切实可行的安全方案。
对应用系统应能提供书面可行的安全方案。
2.3.2在应用系统启始设计阶段实施安全计划
在应用系统启始设计阶段进行充分的安全可行性分析，对应用系统应该进行专门的安全可行性分析。
启始设计阶段同时还要进行风险的最初评估，在被选方案之间权衡效费比关系时，应该参照这个估计值，尤其在重点应用系统项目中应特别注重这方面的考虑。
2.3.3在应用系统开发阶段建立安全机制
安全需求定义：
在软件开发之前，需要了解相关的安全规定和软件运行的环境要求，并对此产生的安全需求做出定义。
安全设计：
安全设计不能简单依附于系统设计的控制而了事，安全的容必须渗透到整个设计阶段。
当然，也不必对每项设计决定都采取安全方法。
通常，有各种方法使其达到必要的安全级别，需要考虑的是如何选择一种折衷方案给安全以适当的地位。
良好的安全设计能明显的减少应用系统的脆弱性并减少在系统运行时安全的强制性。
对于重点类系统应能够提供这方面的细节说明，以证实安全性设计的有效性。
安全的编程方法：
（1） 所有应用系统都应正确选择程序设计语言和其它程序设计工具，从而提高最终产品的可靠性和正确性；为提高整个系统的安全性，要恰当地选择并利用这些工具帮助防止程序错误进入源编码。
（2） 对于重点应用系统应该严格采用软件工程的方法编制程序，对编码至少由一名未参与程序设计的程序员检查程序编码，全面了解它的安全要点，他与原设计者对程序遗留问题应负有同样的责任。
（3） 对于重点应用系统程序库应有仅允许授权人存取程序模块功能，以及记录所有对程序模块存取的安全控制功能。
软件安全性的检测和评估:
公司所有类应用系统 综合运用静态和动态检测技术，进行全面认真的检测和评估，发现在应用系统设计和编码中的错误、疏忽和其它缺陷。
2.3.4在操作运行中保障安全
数据控制:
重点应用系统应从输入准备、数据媒介存储、输出传播各个阶段所需的控制入手，保证数据安全成功处理。
对安全变异的响应:
重点应用系统中，一切与现行安全规定抵触的每一件事或不能解释的结果以及其它异常事件都应视为安全变异现象，应该给予足够的重视，并尽快报告管理员或其他负责人采取必要措施，以减少或消除不安全隐患。
报告方式要、过程要简单。
安全记账与审计：
重点应用系统中，应利用应用系统审计日志进行监控，并作为一种主动的监督管理形式和一种检测触犯安全规定事件的手段。
同时必须加强对应用系统的审计日志类信息的保护，对审计日志和监控功能的使用也必须做审计记录。
2.4接口安全性
2.4.1接口安全性要求
职责分隔：
应用系统接口是易受攻击的脆弱点，重点应用系统中，应从职责管理上加强，将责任实现最佳分离。
明确敏感客体和操作规定：
重点应用系统中，应能够根据可靠性、性和可用性三者定义每个数据客体（数据输入、数据存储和数据输出等）的安全需求，并通过系统实施时的培训来落实。
错误容限规定：
公司各类应用系统对错误的容限度和在可接受的限度维护错误级别的需求必须被定义在安全需求中。
可用性需求：
公司各类应用系统为避免因为系统不能有效使用而产生的严重危害，必须制定可用性需求，然后根据需求采取措施来保证系统的可用性。
2.4.2接口扩展性要求
接口标准性要求：
对于各类应用系统应该能够尽量接口标准化，从而利于应用系统间信息的互通。
对于应用系统建设、改造等有代表性的，需要制定相关接口标准，作为将来工作的参照。
接口规细化程度：
对于各类应用系统接口规应该尽量细化，减少接口描述不清出现新的安全隐患。
对于重点应用系统应该有明确的接口类文档说明部分。
2.5数据安全性
2.5.1数据传输的性
重点应用系统中传输关键、敏感数据时要采用传输加密技术，实现数据性要求；其他类应用系统应根据具体情况来考虑。
密码算法选择:
（1）密码算法必须具有较高的强度和抗攻击能力。
（2）加密信息量大时应使用对称加密算法，加密重要信息时应使用非对称加密算法。
（3）要根据所保护信息的敏感程度与攻击者破解所要花的代价值不值得和系统所要求的反应时间来综合考虑决定要采用的密码算法。
加解密实现方式:
（1）如果要求全通信业务流性，那么应选取物理层加密，或传输安全手段（例如，适当的扩频技术）。
（2）如果要求高粒度保护（即对每个应用联系可能提供不同的密钥）和防抵赖或选择字段保护，应选取表示层加密。
（3）如果希望的是所有端系统到端系统通信的简单块保护，或希望有一个外部的加密设备（例如为了给算法和密钥以物理保护，或防止错误软件），那么应选取网络层加密。
这能够提供性与不带恢复的完整性。
（4）如果要求带恢复的完整性，同时又具有高粒度保护，那么将选取传输层加密。
这能提供性、带恢复的完整性或不带恢复的完整性。
（5）不推荐在数据链路层上加密。
当关系到以上问题中的两项或多项时，加密可能需要在多个层上提供。
2.5.2数据传输的完整性
数据完整性：
对于重点应用系统，因数据在INTERNET上传播或至关重要，应该保障数据的完整性，针对应用系统信息的重要程度，可以采用不同的数据完整性验证手段。
实现完整性方式选择：
（1）由加密提供的数据完整性机制；
（2）基于非对称加密的数据完整性机制，重点类系统应该尽量采用这种方式；
（3）其它数据完整性机制。
2.6用户安全性
2.6.1用户身份认证
对身份认证的需求:
对用户身份认证的需求取决于应用系统的性质，对于重点类系统要采用强身份认证方式。
身份认证的实现:
（1）弱身份认证方式加强：
对口令长度、复杂度、更新周期、性等进行严格管理。
（2）强身份认证方式有效保障：
对重要应用系统应逐渐倾向于加强的身份认证方式来保证用户身份安全，强身份认证方式可采用证书方式或动态口令方式等来实现。
从管理角度考虑：
没有一项身份认证技术是绝对可靠的，须依靠严格的强化管理和用户合作来提高认证技术的可靠性，并根据每个系统的实际需要部署，避免造成不必要的负担而影响应用系统的使用。
2.6.2不可否认性
对核心系统必须考虑不可否认性的功能，重点系统应该逐渐考虑系统操作的不可否认性，不可否认性可以用数字签名等来实现。
2.6.3授权
清晰的授权方案：
对重点系统需要有清晰的授权方案，有时不仅要指明应用哪些系统模块，还要明确使用哪台终端。
其他应用系统应能够满足系统功能、角色划分，满足用户需求。
授权委托时效性：
所有类应用系统的授权机制应该能够处理、识别、取消或修改授权操作的最终结果。
授权数据的保护：
（1） 所有类应用系统的授权系统维护应简单易行,避免发生错误。
（2） 重点应用系统的授权机制应具有自我保护能力。
异常情况或不兼容的授权数据应及早发现并报告。
授权数据必须认真加以保护，以防任何非授权修改和恶意破坏。
2.7应急计划
所有应用系统应制定相应的应急计划，它是重要的应用系统安全防卫措施。
应急计划应该包括操作系统中断、数据库和物理设备被破坏等情况的应急措施，这个计划也应该包括自动或人工过程所需设备的使用步骤。
2.7.1关键功能的鉴别
对于重点应用系统不仅应明确其关键功能的关键作用，而且也应该明确其它功能转变为关键功能之后的那段时间它的作用。
2.7.2替换场所操作
对于重点应用系统要设法在其它部门找到相同或兼容的设备，当紧急情况发生时，这些作为备份的设备有可能分配时间给运行失效的应用系统，这样的替换安排应该是相互的。
此外，针对替换场所的通信要设计出一种方法提供足够的传输设备；对配备的人员要进行有针对性的培训。
2.7.3有限的人工替换处理
必要时，将某些关键功能恢复成人工处理也是一种补偿办法。
对于重点应用系统如果对应用系统运行的持续性要求较高时，人工操作所需的一切必须事前准备妥当，如要考虑工作场所、实时数据的可用性、书面的原始数据、人工使用的特殊设备、报告格式、通信、传送、人员的选择和培训以及及时记录所有人工传递的处理过程等。
2.7.4数据备份
对于重点应用系统应该根据系统的重要程度制定相应的数据备份策略，并加以落实实施，并能熟练实现在发生数据灾难时的数据快速恢复工作。
2.8安全管理
2.8.1建立管理体制
建立管理体制包括建立防组织、健全规章制度和明确职责任务三部分。
管理体制是进行管理的基础，规章制度应在权限的分配过程中建立，并可根据需要参照执行。
重点应用系统应建立良好的管理体制并归档，对于其他类应用系统应逐步完善管理体制。
2.8.2实施管理措施
实施管理措施应以实施存取控制和监督设备运行为主要容。
管理措施是对管理辅之以技术手段，达到强化管理的目的。
重点类应用系统应建立起管理措施对应的规化流程，其他类应用系统也应该明确其管理措施细节，落实到位。
2.8.3加强教育培训
重点类应用系统安全培训应该以普及安全知识、教授安全措施的具体操作为重点。
其他类应用系统应在系统帮助里面注明有关操作条目。
应该是个立体的从网络层-系统层-应用层-后台数据库层面..
都应该考虑
网络层主要考虑数据传输的可靠行和性（数据嗅探，监听，劫持）
系统层主要考虑系统自身安全（权限补丁等等）
应用层考虑代码的强壮性（开发初期就要注意安全的编码习惯）后期上线的白盒（源代码安全评估阅读-主要靠经验），黑盒测试（web的渗透测试安全检测-应用安全典型十大风险，及目前主流的发展变形技术）
数据库层面考虑数据库本身安全补丁端口权限设置（，服务权限二次设置）等
其他还有很多小的方面需要有个总体的列表归纳下需要注意的点
产品方面现在有很多了国国外都有ips（国绿盟，启明的）效果还是不错的（针对应用层说）慢慢会比较多了ps-我们公司就在做要上线了呵呵
总之应用针对的说需要考虑的因素还是比较多的，需要一个有经验的人把握方方面面即便一个地方小的疏忽都很有可能威胁到安全
设备已经很多了。
除了楼主说的外，我认为应该精力更应该放到细节上，比如
系统安全不只是补丁和漏洞。
1、服务器权限。
尽量使用低权限账号，日常登陆服务器及维护站点都用低权限。
---防止误操作降低被攻击风险。
2、服务器密码存放。
---本地存放和密码策略，密码变更管理等。
3、管理服务器用户的IP限制等
4、防DDOS，ARP等
大家都说了这么多了：
我根据自己的经验。
也来说两句。
网络层面：
严格的网络防火墙是必要的。
抗DDOS也是需要考虑的。
同时NIDS可以有效的监控可能带来危害的行为。
网络安全本身也是非常重要的。
【被嗅探这些也是高危险性的。
】
系统层面：
对系统的补丁管理，反病毒，单机防火墙，HIPS，IPSEC,防篡改都能有一些帮助。
但也有些问题。
1，补丁不及时，不全面。
还是被溢出了？
？
2，杀毒软件杀不了毒。
3,由于应用的复杂性，防火墙设置时候往往不能达到权限最小化。
。
。
。
。
。
。
。
。
要解决所有这些问题。
一是每个方面都要加强，同时不要忽略任意一方面。
安全在这里可以说是木桶原理的最好体现了。
应用层面：
主要就是代码本身了。
代码本身若不安全，做太多的措施也是，只要一个sql注入就全玩玩了。
如何编写安全的web代码，可以参照owasp。
个人认为在配iis也有很多的安全窍门。
【比如urlscan过滤啊等】
数据库层：
数据库的安全加固往往大家容易忽略。
这方面可以参考cis相关资料。
另外：
重中之重：
是要建立一套完整的风险管理体系。
风险评估，渗透测试，安全加固等等等等。
架构和访问控制权限上下手，如果为前台静态发布+管理发布生成控制台+后台数据库+各模块，架构安全了，再谈其他的
首先看一下三层架构的组成：
一：
界面层
界面层提供给用户一个视觉上的界面，通过界面层，用户输入数据、获取数据。
界面层同时也提供一定的安全性，确保用户有会看到的信息。
二：
逻辑层
逻辑层是界面层和数据层的桥梁，它响应界面层的用户请求，执行任务并从数据层抓取数据，并将必要的数据传送给界面层。
三：
数据层
数据层定义、维护数据的完整性、安全性，它响应逻辑层的请求，访问数据。
这一层通常由大型的数据库服务器实现，如Oracle、Sybase、MSSQlServer等。
下面是三层架构的优势分析：
从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。
三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。
开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。
三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的存、较慢的CPU就可以获得不错的性能。
相比之下，单层或胖客户对面器的要求太高。
三层架构的另一个优点在于可以更好的支持分布式计算环境。
逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。
分布式计算的潜力巨大，远比升级CPU有效。
三层架构的最大优点是它的安全性。
用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
另外三层架构还可以支持如下功能：
RemoteAccess（远程访问资料），例如可透过Internet存取远程数据库；HighPerformance（提升运算效率）解决集中式运算（Centralize）及主从式架构（Client-Server）中，数据库主机的运算负担，降低数据库主机的ConnectionLoad，并可藉由增加AppServer处理众多的数据处理要求，这一点跟前面讲到的分布式计算提高运算能力是一个道理；Client端发出Request（工作要求）后，便可离线，交由AppServer和DataBaseServer共同把工作完成，减少Client端
的等待时间；这个功能我觉得应用场合不是很多，自己感受也不是很深刻，从理论上是成立的；
这方面的专家请补充和分析一下三层架构在安全性方面的影响，水涨船高啊；
对于asp.net没有专门的研究，仅提供如下思路，供参考：
1、对数据库进行安全配置，例如你的程序连接数据库所使用的/口令/权限，如果是浏览新闻的，用只读权限即可；可以对不同的模块使用不同的/权限；另外，数据库的哪些存储过程可以调用，也要进行严格地配置，用不到的全部禁用（特别是cmd这种），防止注入后利用数据库的存储过程进行系统调用；
2、在获取客户端提交的参数时，进行严格的过滤，包括参数长短、参数类型等等；
3、对管理员后台进行严格的保护，有条件的话，应该设置为只允许特定的IP访问（例如只允许管理员网段访问）——这个要根据实际情况来看的；
4、对操作系统进行安全配置，防止注入后调用系统的功能，例如把cmd.exe/tftp.exe/ftp.exe/net.exe这些文件全部转移到其他目录，并对目录进行严格的权限指派；
5、设置网络访问控制；
6、有条件的话，配置针对HTTP的容过滤，过滤病毒、恶意脚本等；
7、如果有必要，可以考虑选择HTTPS（这样可以防止很多的注入工具扫描，我以前自己开发注入检测工具的时候，考虑过做支持HTTPS方式的，但目前还没付诸实施，相信其他兄弟姐妹考虑到这一点的也不多:
）；
……
相信你也看出来了，总的来说程序方面主要考虑权限、参数过滤等问题；权限主要包括IIS浏览权限、数据库调用权限。
除此以外，还要考虑数据库、操作系统的安全配置。
另外，不知道你们在开发过程中会不会用到其他人开发的组件，例如图片上传之类的，这类组件你们研究过其安全性么？
或者开发的过程中，绝大多数人会使用网上、书上提供的现成代码，例如用户登录验证等等，这些公开代码，也要研究其安全性问题。
只是一个普通的思路而已，谈不上建设性，希望对你有帮助；
要做信息安全规划当然不能凭空去想，去写；我觉得你要做如下几个作业：
那就是你要明确三个问题：
要去哪里？
现在在哪里？
如何去你那里？
1.了解信息安全管理方面的最佳实践和标准，例如iso17799，等；对信息安全管理有一个全貌的了解，心中要装有蓝图；证券行业归口证监会管，证监会的一些针对证券行业的监管要求也要看的，了解外部环境的要求，这些你都是要装到肚子里面的，你叫他蓝图也好，你叫他基线也行，这是你做事情的基准；否则你不知道要去哪里对吧？
2.了解目前你所在的证券公司的信息安全建设现状，以及来自你的管理层的期望（如果是一些战略性的指示那就最好不过了）；这样你会了解到同蓝图相比你们的差距以及高层面的指导，如果这种指导是业务层面的，那么你要想好实现业务层面的目标，信息安全如何帮助你们证券公司去实现业务目标；在这里，你就是要搞清楚，我现在在哪里的问题。
3.根据你了解的差距，以及领导的期望，结合你们现在的实际情况（例如资源、围等）整理出近期、中期、远期的建设路线，或者叫安全能力提升路线。
在这里，你基本上要搞清楚，我应当怎么去我要去的地方。
当然，第2、3步要做的话，还是需要去看一些更详细的资料，看如何落实；例如是不是考虑通过风险评估来做现状分析，那么你要看一些风险评估方面的标准和资料；能力演进路线的确定也要有一些要素考虑，特别是安全能力提升优先级上，例如外部监管要求、你们公司实际面临的紧急问题、你们的财力、人力，目前市场上的技术和能力等等。
这种规划类的东西，可繁可简，根据你们的具体情况来看了，看你老板想要什么样的东西；找咨询公司做，怕是要花上不少银子和时间，自己鼓捣一下，也未必过不了关。
试用过IBM的AppScan，这玩意本身就做成了一个的形式，提交个URL，配置些policy，就可以扫描了，用起来比较方便。
然后扫描了一下他给的样例，发现扒取功能比较强大，而且扫出了不少漏洞，例如配置文件没有隐藏，XSS，还有各种Injection。
然后就拿它去扫了一下原来测试过的一个WebAPP。
很遗憾，什么漏洞都没有发现。
但是我们测过的这个WebAPP本身是有很多漏洞的，代码级别的有n个XSS，SQLInjection。
于是我花了点时间，看它是怎么识别漏洞的。
以SQLInjection为例，他通过在request里塞入特殊字符，然后就观察返回的response有没有出现数据库异常的Exception，通过提取关键字来发现是否有SQL注入漏洞。
但是如果APP里对异常包装的比较好，或者压根就不抛异常，它就没辙了。
也就说，他也许已经注入成功了，但是没法识别是否成功。
而我又看了下XSS是怎么识别的，同理，也是在request里塞一段代码，然后看紧跟的response里有没有这段代码。
但是大家都知道StoredXSS是把代码存在数据库里的，也许是其他页面才能看到，或者压根是别人才能看到，所以它同样没辙。
上述的还是漏报，我经历过一次误报就更搞笑了。
paros提供简单的扫描功能，有一次用它扫描，居然发现了sql注入漏洞，但是看过代码认为这个漏洞是不会发生的，于是看了下细节，笑翻了。
它在request里塞了一段代码，意思是让数据库20秒后再反应，结果可能当时那个response真的是20秒后再过来的，于是它就认为注入成功了。
所以我觉得自动化测试工具本身是有局限性的，误报漏报很正常，因为对漏洞的侦测可能需要综合一些现象去判断，工具的AI只能覆盖部分容。
今天上午，HP的WebInspect的一个老外远程给我们做他们产品的培训，看了下它家的产品，他提出的是一揽子解决方案，从设计，开发，测试等阶段都有他们的相关产品，最后还有个什么控制工具能图形化的管理这些流程中存在的风险点。
最后演示了下他们的漏洞扫描功能，跟APPScan差不多，问他原理是怎么样的，他不知道是没听懂还是故意闪烁其词，反正就是没讲原理咋样。
我觉得楼主要买这些产品的话，先要摆正这个产品的位置。
我很同意mimime的说法，自动化扫描工具能提供参考，缩小围，加快效率，但是千万不能迷信，一套合理的流程是必须的。
设计时就考虑安全，编代码时要符合bestpractice，测试时先工具扫描再人工扫描，有条件的话还可以找黑客做渗透性测试。
所以楼主在评估时，可以考虑哪个软件能很好地融入公司的开发流程，方便风险管理，至于漏洞扫描，可以自己找个自己清楚的评估下，看看哪个AI强一点，不要用它提供的样例。
大概可以从这么几个方面考虑：
1.操作系统自身的安全性，端口，服务，补丁，安全策略
管理员口令强度，本地/远程登录维护策略，日志及分析等措施
详细容可以搜索查找
2.IIS，或者Apache，或者其他相关WEB服务器程序的安全性
具体容可以搜索一下，关于这方面的容挺多的
3.程序自身的安全性，注意是否有明显可以被利用的漏洞和不足
敏感字符过滤，防止SQL注入，定期检查，防止代码被修改，被挂载木马
等等
4.后台数据库的安全性，重要数据是否考虑加密，补丁，数据备份
不必要存储过程的删除，用户权限控制，管理员口令等等
详细容可以搜索一下
5.客户的重要商业信息如果不是很必要的话，最好还是保存到其他的隔离
主机当中，如果实在不能实现，可以考虑对数据进行加密处理
6.不知道这台WEB服务器前端有没有部署防火墙，如果已经使用防火墙
可以在防火墙设置相应严格的访问控制策略
8.安装防病毒软件及时升级病毒库，再服务器负载，访问量不是很大时进
行病毒查杀
PS：
如果程序只是一些静态网页，而且更新周期比较长（4个月，
6个月，更长）可以考虑把程序可录到光盘里，或者存储到U盘中
并且把U盘写保护打开，使U盘中容只能够读取。
暂时想到这么多，在补充吧
保证数据库系统的安全
随着计算机技术的飞速发展，数据库的应用十分广泛，深入到各个领域，但随之而来产生了数据的安全问题。
各种应用系统的数据库量数据的安全问题、敏感数据的防窃取和防篡改问题，越来越引起人们的高度重视。
数据库系统作为信息的聚集体，是计算机信息系统的核心部件，其安全性至关重要，关系到企业兴衰、成败。
因此，如何有效地保证数据库系统的安全
升级会员 