应用系统安全规范制定建议

应用系统安全规范制定建议

应用系统安全是当前众多大型企业要重点关注的问题, 但这块有好多工作要做, 现状是现在很多做安全的人, 不怎么太做开发, 做开发的人懂安全的人又少之又少, 这里我从应用系统安全, 提出几点自己的建议, 当然不足之处还请大家讨论和指正。

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 、MS SQl Server等。

下面是三层架构的优势分析:

从开发角度和应用角度来看,三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发,每人可以有不同的分工,协同工作使效率倍增。开发双层或单层应用时,每个开发人员都应对系统有较深的理解,能力要求很高,开发三层应用时,则可以结合多方面的人才,只需少数人对系统全面了解,从一定程度工降低了开发的难度。

三层架构属于瘦客户的模式,用户端只需一个较小的硬盘、较小的内存、较慢的CPU 就可以获得不错的性能。相比之下,单层或胖客户对面器的要求太高。

三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行,充分利用网络的计算功能。分布式计算的潜力巨大,远比升级CPU 有效。 三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层,减少了入口点,把很多危险的系统功能都屏蔽了。

另外三层架构还可以支持如下功能:Remote Access(远程访问资料) ,例如可透过Internet 存取远程数据库;High Performance(提升运算效率) 解决集中式运算(Centralize)及主从式架构(Client-Server)中,数据库主机的运算负担,降低数据库主机的Connection Load,并可藉由增加App Server处理众多的数据处理要求,这一点跟前面讲到的分布式计算提高运算能力是一个道理;Client 端发出Request(工作要求) 后,便可离线,交由App Server和DataBase Server共同把工作完成,减少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 。然后就拿它去扫了一下原来测试过的一个Web APP。很遗憾,什么漏洞都没有发现。但是我们测过的这个Web APP本身是有很多漏洞的,代码级别的有n 个XSS ,SQL Injection。

于是我花了点时间,看它是怎么识别漏洞的。以SQL Injection 为例,他通过在request 里塞入特殊字符,然后就观察返回的response 有没有出现数据库异常的Exception ,通过提取关键字来发现是否有SQL 注入漏洞。但是如果APP 里对异常包装的比较好,或者压根就不抛异常,它就没辙了。也就说,他也许已经注入成功了,但是没法识别是否成功。而我又看了下XSS 是怎么识别的,同理,也是在request 里塞一段代码,然后看紧跟的response 里有没有这段代码。但是大家都知道Stored XSS是把代码存在数据库里的,也许是其他页面才能看到,或者压根是别人才能看到,所以它同样没辙。上述的还是漏报,我经历过一次误报就更搞笑了。paros 提供简单的扫描功能,有一次用它扫描,居然发现了sql 注入漏洞,但是看过代码认为这个漏洞是不会发生的,于是看了下细节,笑翻了。它在request 里塞了一段代码,意思是让数据库20秒后再反应,结果可能当时那个response 真的是20秒后再过来的,于是它就认为注入成功了。所以我觉得自动化测试工具本身是有局限性的,误报漏报很正常,因为对漏洞的侦测可能需要综合一些现象去判断,工具的AI 只能覆盖部分内容。

今天上午,HP 的WebInspect 的一个老外远程给我们做他们产品的培训,看了下它家的产品,他提出的是一揽子解决方案,从设计,开发,测试等阶段都有他们的相关产品,最后还有个什么控制工具能图形化的管理这些流程中存在的风险点。最后演示了下他们的漏洞扫描功能,跟APP Scan差不多,问他原理是怎么样的,他不知道是没听懂还是故意闪烁其词,反正就是没讲原理咋样。

我觉得楼主要买这些产品的话,先要摆正这个产品的位置。我很同意mimime 的说法,自动化扫描工具能提供参考,缩小范围,加快效率,但是千万不能迷信,一套合理的流程是必须的。设计时就考虑安全,编代码时要符合best practice,测试时先工具扫描再人工扫描,有条件的话还可以找黑客做渗透性测试。所以楼主在评估时,可以考虑哪个软件能很好地融入公司的开发流程,方便风险管理,至于漏洞扫描,可以自己找个自己清楚的网站评估下,看看哪个AI 强一点,不要用它提供的样例网站。

大概可以从这么几个方面考虑:

1. 操作系统自身的安全性,端口,服务,补丁,安全策略

管理员口令强度,本地/远程登录维护策略,日志及分析等措施

详细内容可以搜索查找

2.IIS ,或者Apache ,或者其他相关WEB 服务器程序的安全性

具体内容可以搜索一下,关于这方面的内容挺多的

3. 网站程序自身的安全性,注意是否有明显可以被利用的漏洞和不足

敏感字符过滤,防止SQL 注入,定期检查,防止代码被修改,被挂载木马

等等

4. 后台数据库的安全性,重要数据是否考虑加密,补丁,数据备份

不必要存储过程的删除,用户权限控制,管理员口令等等

详细内容可以搜索一下

5. 客户的重要商业信息如果不是很必要的话,最好还是保存到其他的隔离

主机当中,如果实在不能实现,可以考虑对数据进行加密处理

6. 不知道这台WEB 服务器前端有没有部署防火墙,如果已经使用防火墙

可以在防火墙设置相应严格的访问控制策略

8. 安装防病毒软件及时升级病毒库,再服务器负载,访问量不是很大时进

行病毒查杀

PS :如果网站程序只是一些静态网页,而且更新周期比较长(4个月,

6个月,更长)可以考虑把网站程序可录到光盘里,或者存储到U 盘中

并且把U 盘写保护打开,使U 盘中内容只能够读取。

暂时想到这么多,在补充吧

保证数据库系统的安全

随着计算机技术的飞速发展,数据库的应用十分广泛,深入到各个领域,但随之而来产生了数据的安全问题。各种应用系统的数据库中大量数据的安全问题、敏感数据的防窃取和防篡改问题,越来越引起人们的高度重视。数据库系统作为信息的聚集体,是计算机信息系统的核心部件,其安全性至关重要,关系到企业兴衰、成败。因此,如何有效地保证数据库系统的安全,实现数据的保密性、完整性和有效性,已经成为业界人士探索研究的重要课题之一,本文就安全防入侵技术做简要的讨论。

数据库系统的安全除依赖自身内部的安全机制外,还与外部网络环境、应用环境、从业人员素质等因素息息相关,因此,从广义上讲,数据库系统的安全框架可以划分为三个层次:

(1)网络系统层次;

(2)宿主操作系统层次;

(3)数据库管理系统层次。

这三个层次构筑成数据库系统的安全体系,与数据安全的关系是逐步紧密的,防范的重要性也逐层加强,从外到内、由表及里保证数据的安全。下面就安全框架的三个层次展开论述。

1. 网络系统层次安全技术

从广义上讲,数据库的安全首先依赖于网络系统。随着Internet 的发展和普及,越来越多的公司将其核心业务向互联网转移,各种基于网络的数据库应用系统如雨后春笋般涌现出来,面向网络用户提供各种信息服务。可以说网络系统是数据库应用的外部环境和基础,数据库系统要发挥其强大作用离不开网络系统的支持,数据库系统的用户(如异地用户、分布式用户) 也要通过网络才能访问数据库的数据。网络系统的安全是数据库安全的第一道屏障,外部入侵首先就是从入侵网络系统开始的。网络入侵试图破坏信息系统的完整性、机密性或可信任的任何网络活动的集合,具有以下特点:

a) 没有地域和时间的限制,跨越国界的攻击就如同在现场一样方便;

b) 通过网络的攻击往往混杂在大量正常的网络活动之中,隐蔽性强;

c) 入侵手段更加隐蔽和复杂。

计算机网络系统开放式环境面临的威胁主要有以下几种类型:

a) 欺骗(Masquerade);

b) 重发(Replay);

c) 报文修改(Modification of message);

d) 拒绝服务(Deny of service);

e) 陷阱门(Trapdoor);

f) 特洛伊木马(Trojan horse);

g) 攻击,如透纳攻击(Tunneling Attack) 、应用软件攻击等。这些安全威胁是无时、无处不在的,因此必须采取有效的措施来保障系统的安全。

从技术角度讲,网络系统层次的安全防范技术有很多种,大致可以分为防火墙、入侵检测、协作式入侵检测技术等。

(1)防火墙是应用最广的一种防范技术:

作为系统的第一道防线,其主要作用是监控可信任网络和不可信任网络之间的访问通道,可在内部与外部网络之间形成一道防护屏障,拦截来自外部的非法访问并阻止内部信息的外泄,但它无法阻拦来自网络内部的非法操作。它根据事先设定的规则来确定是否拦截信息流的进出,但无法动态识别或自适应地调整规则,因而其智能化程度很有限。防火墙技术主要有三种:数据包过滤器(packet filter) 、代理(proxy)和状态分析(stateful inspection) 。现代防火墙产品通常混合使用这几种技术。

(2)入侵检测(IDS—Instrusion Detection System)是近年来发展起来的一种防范技术:

综合采用了统计技术、规则方法、网络通信技术、人工智能、密码学、推理等技术和方法,其作用是监控网络和计算机系统是否出现被入侵或滥用的征兆。1987年,Derothy Denning 首次提出了一种检测入侵的思想,经过不断发展和完善,作为监控和识别攻击的标准解决方案,IDS 系统已经成为安全防御系统的重要组成部分。

入侵检测采用的分析技术可分为三大类:签名、统计和数据完整性分析法。

①签名分析法:

主要用来监测对系统的已知弱点进行攻击的行为。人们从攻击模式中归纳出它的签名,编写到IDS 系统的代码里。签名分析实际上是一种模板匹配操作。

②统计分析法:

以统计学为理论基础,以系统正常使用情况下观察到的动作模式为依据来判别某个动作是否偏离了正常轨道。

③数据完整性分析法:

以密码学为理论基础,可以查证文件或者对象是否被别人修改过。

IDS 的种类包括基于网络和基于主机的入侵监测系统、基于特征的和基于非正常的入侵监测系统、实时和非实时的入侵监测系统等。

(3)协作式入侵监测技术:

独立的入侵监测系统不能够对广泛发生的各种入侵活动都做出有效的监测和反应,为了弥补独立运作的不足,人们提出了协作式入侵监测系统的想法。在协作式入侵监测系统中,IDS 基于一种统一的规范,入侵监测组件之间自动地交换信息,并且通过信息的交换得到了对入侵的有效监测,可以应用于不同的网络环境。

2. 宿主操作系统层次安全技术

操作系统是大型数据库系统的运行平台,为数据库系统提供一定程度的安全保护。目前操作系统平台大多数集中在Windows NT 和Unix ,安全级别通常为C1、C2级。主要安全技术有操作系统安全策略、安全管理策略、数据安全等方面。

操作系统安全策略用于配置本地计算机的安全设置,包括密码策略、账户锁定策略、审核策略、IP 安全策略、用户权利指派、加密数据的恢复代理以及其它安全选项。具体可以体现在用户账户、口令、访问权限、审计等方面。

◆用户账户:用户访问系统的“身份证”,只有合法用户才有账户。

◆口令:用户的口令为用户访问系统提供一道验证。

◆访问权限:规定用户的权限。

◆审计:对用户的行为进行跟踪和记录,便于系统管理员分析系统的访问情况以及事后的追查使用。

应用软件安全

应用软件安全性应考虑三方面,个人认为:

(1)安全架构设计;

(2)安全编程

(3)安全测试。

如果按照CC 要求,还有就是安全保障!

首先,信息安全是一个体系,不是孤立的几个不同步骤,目的是保护核心数据安全。

其次,信息安全体系遵从木桶原则,信息安全体系的防护程度取决于体系中最短的一块木桶。 所以,我认为体系中那个部分做的最薄弱,那个部分最重要,只有加长了短木板,整体防护才能上一个新水平,才能谈到下一步继续发展

发表于: 2007-11-21 16:35 发表主题: 个人见解, 仅供参考

我觉得最重要的是意识、是对安全的认识

安全不是一个人、几个人或者某个部门的事情,而是整个企业的事情

仅仅依靠技术、管理制度去维系企业的信息安全,则很难保障不会出现内部威胁,而内部威胁对信息安全而言,是很要命的事情。

只有整个企业的人员,自上而下都认识到安全的重要性,具有维护本企业内部信息安全的意识,主动地遵循制定好的管理规则,将信息安全保护的意识贯彻到日常的行为中去,才能真正的保障企业的信息安全。

这里面,对员工日常的安全意识的培训教育是一方面,员工本身的职业道德素养的培养又是另一方面。

安全首先要贯彻到人的意识中去,企业负责人重视安全的保障问题,技术部门认真管理安全技术设置,多个方面齐发并行,才能真正的实现企业的信息安全保证。

但这些方面的基础设施是人员对安全的意识与认识!

应用系统安全规范制定建议

应用系统安全是当前众多大型企业要重点关注的问题, 但这块有好多工作要做, 现状是现在很多做安全的人, 不怎么太做开发, 做开发的人懂安全的人又少之又少, 这里我从应用系统安全, 提出几点自己的建议, 当然不足之处还请大家讨论和指正。

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 、MS SQl Server等。

下面是三层架构的优势分析:

从开发角度和应用角度来看,三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发,每人可以有不同的分工,协同工作使效率倍增。开发双层或单层应用时,每个开发人员都应对系统有较深的理解,能力要求很高,开发三层应用时,则可以结合多方面的人才,只需少数人对系统全面了解,从一定程度工降低了开发的难度。

三层架构属于瘦客户的模式,用户端只需一个较小的硬盘、较小的内存、较慢的CPU 就可以获得不错的性能。相比之下,单层或胖客户对面器的要求太高。

三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行,充分利用网络的计算功能。分布式计算的潜力巨大,远比升级CPU 有效。 三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层,减少了入口点,把很多危险的系统功能都屏蔽了。

另外三层架构还可以支持如下功能:Remote Access(远程访问资料) ,例如可透过Internet 存取远程数据库;High Performance(提升运算效率) 解决集中式运算(Centralize)及主从式架构(Client-Server)中,数据库主机的运算负担,降低数据库主机的Connection Load,并可藉由增加App Server处理众多的数据处理要求,这一点跟前面讲到的分布式计算提高运算能力是一个道理;Client 端发出Request(工作要求) 后,便可离线,交由App Server和DataBase Server共同把工作完成,减少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 。然后就拿它去扫了一下原来测试过的一个Web APP。很遗憾,什么漏洞都没有发现。但是我们测过的这个Web APP本身是有很多漏洞的,代码级别的有n 个XSS ,SQL Injection。

于是我花了点时间,看它是怎么识别漏洞的。以SQL Injection 为例,他通过在request 里塞入特殊字符,然后就观察返回的response 有没有出现数据库异常的Exception ,通过提取关键字来发现是否有SQL 注入漏洞。但是如果APP 里对异常包装的比较好,或者压根就不抛异常,它就没辙了。也就说,他也许已经注入成功了,但是没法识别是否成功。而我又看了下XSS 是怎么识别的,同理,也是在request 里塞一段代码,然后看紧跟的response 里有没有这段代码。但是大家都知道Stored XSS是把代码存在数据库里的,也许是其他页面才能看到,或者压根是别人才能看到,所以它同样没辙。上述的还是漏报,我经历过一次误报就更搞笑了。paros 提供简单的扫描功能,有一次用它扫描,居然发现了sql 注入漏洞,但是看过代码认为这个漏洞是不会发生的,于是看了下细节,笑翻了。它在request 里塞了一段代码,意思是让数据库20秒后再反应,结果可能当时那个response 真的是20秒后再过来的,于是它就认为注入成功了。所以我觉得自动化测试工具本身是有局限性的,误报漏报很正常,因为对漏洞的侦测可能需要综合一些现象去判断,工具的AI 只能覆盖部分内容。

今天上午,HP 的WebInspect 的一个老外远程给我们做他们产品的培训,看了下它家的产品,他提出的是一揽子解决方案,从设计,开发,测试等阶段都有他们的相关产品,最后还有个什么控制工具能图形化的管理这些流程中存在的风险点。最后演示了下他们的漏洞扫描功能,跟APP Scan差不多,问他原理是怎么样的,他不知道是没听懂还是故意闪烁其词,反正就是没讲原理咋样。

我觉得楼主要买这些产品的话,先要摆正这个产品的位置。我很同意mimime 的说法,自动化扫描工具能提供参考,缩小范围,加快效率,但是千万不能迷信,一套合理的流程是必须的。设计时就考虑安全,编代码时要符合best practice,测试时先工具扫描再人工扫描,有条件的话还可以找黑客做渗透性测试。所以楼主在评估时,可以考虑哪个软件能很好地融入公司的开发流程,方便风险管理,至于漏洞扫描,可以自己找个自己清楚的网站评估下,看看哪个AI 强一点,不要用它提供的样例网站。

大概可以从这么几个方面考虑:

1. 操作系统自身的安全性,端口,服务,补丁,安全策略

管理员口令强度,本地/远程登录维护策略,日志及分析等措施

详细内容可以搜索查找

2.IIS ,或者Apache ,或者其他相关WEB 服务器程序的安全性

具体内容可以搜索一下,关于这方面的内容挺多的

3. 网站程序自身的安全性,注意是否有明显可以被利用的漏洞和不足

敏感字符过滤,防止SQL 注入,定期检查,防止代码被修改,被挂载木马

等等

4. 后台数据库的安全性,重要数据是否考虑加密,补丁,数据备份

不必要存储过程的删除,用户权限控制,管理员口令等等

详细内容可以搜索一下

5. 客户的重要商业信息如果不是很必要的话,最好还是保存到其他的隔离

主机当中,如果实在不能实现,可以考虑对数据进行加密处理

6. 不知道这台WEB 服务器前端有没有部署防火墙,如果已经使用防火墙

可以在防火墙设置相应严格的访问控制策略

8. 安装防病毒软件及时升级病毒库,再服务器负载,访问量不是很大时进

行病毒查杀

PS :如果网站程序只是一些静态网页,而且更新周期比较长(4个月,

6个月,更长)可以考虑把网站程序可录到光盘里,或者存储到U 盘中

并且把U 盘写保护打开,使U 盘中内容只能够读取。

暂时想到这么多,在补充吧

保证数据库系统的安全

随着计算机技术的飞速发展,数据库的应用十分广泛,深入到各个领域,但随之而来产生了数据的安全问题。各种应用系统的数据库中大量数据的安全问题、敏感数据的防窃取和防篡改问题,越来越引起人们的高度重视。数据库系统作为信息的聚集体,是计算机信息系统的核心部件,其安全性至关重要,关系到企业兴衰、成败。因此,如何有效地保证数据库系统的安全,实现数据的保密性、完整性和有效性,已经成为业界人士探索研究的重要课题之一,本文就安全防入侵技术做简要的讨论。

数据库系统的安全除依赖自身内部的安全机制外,还与外部网络环境、应用环境、从业人员素质等因素息息相关,因此,从广义上讲,数据库系统的安全框架可以划分为三个层次:

(1)网络系统层次;

(2)宿主操作系统层次;

(3)数据库管理系统层次。

这三个层次构筑成数据库系统的安全体系,与数据安全的关系是逐步紧密的,防范的重要性也逐层加强,从外到内、由表及里保证数据的安全。下面就安全框架的三个层次展开论述。

1. 网络系统层次安全技术

从广义上讲,数据库的安全首先依赖于网络系统。随着Internet 的发展和普及,越来越多的公司将其核心业务向互联网转移,各种基于网络的数据库应用系统如雨后春笋般涌现出来,面向网络用户提供各种信息服务。可以说网络系统是数据库应用的外部环境和基础,数据库系统要发挥其强大作用离不开网络系统的支持,数据库系统的用户(如异地用户、分布式用户) 也要通过网络才能访问数据库的数据。网络系统的安全是数据库安全的第一道屏障,外部入侵首先就是从入侵网络系统开始的。网络入侵试图破坏信息系统的完整性、机密性或可信任的任何网络活动的集合,具有以下特点:

a) 没有地域和时间的限制,跨越国界的攻击就如同在现场一样方便;

b) 通过网络的攻击往往混杂在大量正常的网络活动之中,隐蔽性强;

c) 入侵手段更加隐蔽和复杂。

计算机网络系统开放式环境面临的威胁主要有以下几种类型:

a) 欺骗(Masquerade);

b) 重发(Replay);

c) 报文修改(Modification of message);

d) 拒绝服务(Deny of service);

e) 陷阱门(Trapdoor);

f) 特洛伊木马(Trojan horse);

g) 攻击,如透纳攻击(Tunneling Attack) 、应用软件攻击等。这些安全威胁是无时、无处不在的,因此必须采取有效的措施来保障系统的安全。

从技术角度讲,网络系统层次的安全防范技术有很多种,大致可以分为防火墙、入侵检测、协作式入侵检测技术等。

(1)防火墙是应用最广的一种防范技术:

作为系统的第一道防线,其主要作用是监控可信任网络和不可信任网络之间的访问通道,可在内部与外部网络之间形成一道防护屏障,拦截来自外部的非法访问并阻止内部信息的外泄,但它无法阻拦来自网络内部的非法操作。它根据事先设定的规则来确定是否拦截信息流的进出,但无法动态识别或自适应地调整规则,因而其智能化程度很有限。防火墙技术主要有三种:数据包过滤器(packet filter) 、代理(proxy)和状态分析(stateful inspection) 。现代防火墙产品通常混合使用这几种技术。

(2)入侵检测(IDS—Instrusion Detection System)是近年来发展起来的一种防范技术:

综合采用了统计技术、规则方法、网络通信技术、人工智能、密码学、推理等技术和方法,其作用是监控网络和计算机系统是否出现被入侵或滥用的征兆。1987年,Derothy Denning 首次提出了一种检测入侵的思想,经过不断发展和完善,作为监控和识别攻击的标准解决方案,IDS 系统已经成为安全防御系统的重要组成部分。

入侵检测采用的分析技术可分为三大类:签名、统计和数据完整性分析法。

①签名分析法:

主要用来监测对系统的已知弱点进行攻击的行为。人们从攻击模式中归纳出它的签名,编写到IDS 系统的代码里。签名分析实际上是一种模板匹配操作。

②统计分析法:

以统计学为理论基础,以系统正常使用情况下观察到的动作模式为依据来判别某个动作是否偏离了正常轨道。

③数据完整性分析法:

以密码学为理论基础,可以查证文件或者对象是否被别人修改过。

IDS 的种类包括基于网络和基于主机的入侵监测系统、基于特征的和基于非正常的入侵监测系统、实时和非实时的入侵监测系统等。

(3)协作式入侵监测技术:

独立的入侵监测系统不能够对广泛发生的各种入侵活动都做出有效的监测和反应,为了弥补独立运作的不足,人们提出了协作式入侵监测系统的想法。在协作式入侵监测系统中,IDS 基于一种统一的规范,入侵监测组件之间自动地交换信息,并且通过信息的交换得到了对入侵的有效监测,可以应用于不同的网络环境。

2. 宿主操作系统层次安全技术

操作系统是大型数据库系统的运行平台,为数据库系统提供一定程度的安全保护。目前操作系统平台大多数集中在Windows NT 和Unix ,安全级别通常为C1、C2级。主要安全技术有操作系统安全策略、安全管理策略、数据安全等方面。

操作系统安全策略用于配置本地计算机的安全设置,包括密码策略、账户锁定策略、审核策略、IP 安全策略、用户权利指派、加密数据的恢复代理以及其它安全选项。具体可以体现在用户账户、口令、访问权限、审计等方面。

◆用户账户:用户访问系统的“身份证”,只有合法用户才有账户。

◆口令:用户的口令为用户访问系统提供一道验证。

◆访问权限:规定用户的权限。

◆审计:对用户的行为进行跟踪和记录,便于系统管理员分析系统的访问情况以及事后的追查使用。

应用软件安全

应用软件安全性应考虑三方面,个人认为:

(1)安全架构设计;

(2)安全编程

(3)安全测试。

如果按照CC 要求,还有就是安全保障!

首先,信息安全是一个体系,不是孤立的几个不同步骤,目的是保护核心数据安全。

其次,信息安全体系遵从木桶原则,信息安全体系的防护程度取决于体系中最短的一块木桶。 所以,我认为体系中那个部分做的最薄弱,那个部分最重要,只有加长了短木板,整体防护才能上一个新水平,才能谈到下一步继续发展

发表于: 2007-11-21 16:35 发表主题: 个人见解, 仅供参考

我觉得最重要的是意识、是对安全的认识

安全不是一个人、几个人或者某个部门的事情,而是整个企业的事情

仅仅依靠技术、管理制度去维系企业的信息安全,则很难保障不会出现内部威胁,而内部威胁对信息安全而言,是很要命的事情。

只有整个企业的人员,自上而下都认识到安全的重要性,具有维护本企业内部信息安全的意识,主动地遵循制定好的管理规则,将信息安全保护的意识贯彻到日常的行为中去,才能真正的保障企业的信息安全。

这里面,对员工日常的安全意识的培训教育是一方面,员工本身的职业道德素养的培养又是另一方面。

安全首先要贯彻到人的意识中去,企业负责人重视安全的保障问题,技术部门认真管理安全技术设置,多个方面齐发并行,才能真正的实现企业的信息安全保证。

但这些方面的基础设施是人员对安全的意识与认识!


相关文章

  • 2011版安全生产法及相关法律法规7章
  • 安全生产法及相关法律法规 第七章 安全生产标准体系 第一节 安全标准概述 安全标准是我国安全生产法律体系的重要组成部分.法定的根据<标准化法>的规定,标准有国家标准.行业标准.地方标准和企业标准,国家标准.行业标准又分为强制性标 ...查看


  • 启动前安全检查规范
  • 启动前安全检查规范 目录 1 范围和应用领域................................................... 3 1.1 目的 ..................................... ...查看


  • 煤教安全教育实践活动整改方案
  • 贵州华瑞鼎兴能源有限公司文件 华瑞能源[2015]第0055号 签发人:武凤林 开展煤矿安全教育实践活动整改方案 一.公司基本情况 贵州华瑞鼎兴能源有限公司(以下简称"公司"), 属北京华瑞世纪控股集团有限公司(以下简称 ...查看


  • 非煤矿山安全管理制度汇编
  • 非煤矿山安全管理制度汇编 目录 一.安全生产方针管理制度..........................................1 二.安全生产目标管理制度.................................... ...查看


  • 行业规范-iso9000-中国电信通信网络安全防护管理办法
  • 中国电信通信网络安全防护管理办法 第一章总则 第一条 为加强中国电信通信网络安全管理工作,提高通信网络安全防护能力,保障通信网络安全畅通,根据<通 信网络安全防护管理办法>(中华人民共和国工业和信息化部第11号令),制定本办法. ...查看


  • 小学教师教材教法测试信息技术试题
  • 丰都县2011年春季开学视导 学校考核等次.特色或亮点.问题及建议 第一视导组: 丰都中学:良 特色或亮点:一是环境打造成效明显,育人氛围浓厚:二是开学工作启动早.谋划实,高三毕业班工作推进有力:三是落实"361"措施, ...查看


  • 民政局加强履职尽责接受督促检查工作汇报
  • 民政局加强履职尽责接受督促检查工作汇报 今年5月以来,按照省.市加强政府部门履职尽责督促检查工作的安排部署,以敢于亮剑.勇于担当的精神,树立"争第一.保优秀"的目标,加强领导.精心组织,全面深入推进全市民政系统加强履职尽 ...查看


  • 数据中心运维操作标准及流程
  • 数据中心运维操作标准及流程 北京科海致能科技有限公司 二零一六年 1机房运维管理前期准备 1.1 管理目标 机房基础设施运维团队应与业主管理层.IT 部门.相关业务部门共同讨论确定运维管理目标.制定目标时,应综合考虑机房所支持的应用的可用性 ...查看


  • 安健环管理体系评审管理标准
  • Q/XXX-XXX x x x x x x x x x 有限公司 x x x x x x x x x 厂企业标准 Q/XXX-XXX 2009-2017 安健环管理体系评审管理标准 2017-06-30 发布 2017-07-01 实施 Q ...查看


  • 关于加强全国合理用药监测工作的通知
  • 关于加强全国合理用药监测工作的通知 卫办医政发[2009]13号 各省.自治区.直辖市卫生厅局.中医药管理局,新疆生产建设兵团卫生局,各军区联勤部.各军兵种后勤部卫生部,总参三部后勤部,总参管理保障部.总政直工部.总装后勤部卫生局,军事科学 ...查看


热门内容