前言:我们精心挑选了数篇优质软件安全论文文章,供您阅读参考。期待这些文章能为您带来启发,助您在写作的道路上更上一层楼。
电子政务系统的应用软件一般规模比较大,软件在应用过程中面向的用户较多,系统结构和业务流程相对复杂,以Web应用为主要实现方式。因而,系统安全常见的风险主要有Web应用的SQL注入漏洞、表单绕过漏洞、上传绕过漏洞、权限绕过漏洞、数据库下载漏洞等。同时也常常存在应用系统管理员账户空口令或弱口令、未设置应用账户口令复杂度限制、无应用系统登录和操作日志等风险。在软件应用安全层面,安全方面的保证没有统一的方法和手段。在保证整个系统安全运行过程中针对信息安全的部分,如对数据库访问安全,访问控制,加密与鉴别等应用层面的安全防护,主要从客户端避免和减少人为非法利用应用程序,从应用软件设计、实现到使用维护,以及应用软件对系统资源、信息的访问等方面保证安全。
二、软件应用安全要求与技术防护
2.1身份鉴别与访问控制
用户身份认证是保护信息系统安全的一道重要防线,认证的失败可能导致整个系统安全防护的失败。电子政务系统的用户对系统资源访问之前,应通过口令、标记等方式完成身份认证,阻止非法用户访问系统资源。从技术防护的角度来说,软件应保障对所有合法用户建立账号,并在每次用户登录系统时进行鉴别。软件应用管理员应设置一系列口令控制规则,如口令长度、口令多次失败后的账户锁定,强制口令更新等,以确保口令安全。软件应用中对用户登录全过程应具有显示、记录及安全警示功能。用户正常登录后,为防止长时间登录而被冒用等情况,系统应有自动退出等登录失效处理功能。此外,应用系统需要及时清除存储空间中关于用户身份的鉴别信息,如客户端的cookie等。系统软件应用中的文件、数据库等客体资源不是所有用户都允许访问的,访问时应符合系统的安全策略。系统中许多应用软件在设计和使用过程中经常会有权限控制不精确,功能划分过于笼统等现象,影响了系统的安全使用。目前,从应用软件的研发和技术实现来看,授权访问控制机制多采用数据库用户和应用客户端用户分离的方式,访问控制的粒度达到主体为用户级,客体为文件、数据库表级。在分配用户权限时,用户所具有的权限应该与其需使用的功能相匹配,不分配大于其使用功能的权限,即分配所谓“最小授权”原则。对于系统的一些特殊用户或角色(如管理和审计)如分配的权限过大,则系统安全风险将过于集中,因此,应将特别权限分配给不同的用户,并在他们之间形成相互制约的关系。
2.2通信安全
电子政务系统应用软件的设计、研发以及应用过程中,需要重点关注通信安全,特别是对通信完整性的保护。除应用加密通信外,通信双方还应根据约定的方法判断对方信息的有效性。在信息通信过程中,为使通信双方之间能正确地传输信息,需要建立一整套关于信息传输顺序、信息格式和信息内容等的约定,因为仅仅使用网络通信协议仍然无法对应用层面的通信完整性提供安全保障,还需在软件层面设计并实现可自定义的供双方互为验证的工作机制。而且,为防止合法通信的抵赖,系统应具有在请求的情况下为数据原发者或接收者提供数据原发或数据接收证据的功能。为保障信息系统通信的保密性,应用软件需具备在通信双方建立连接之前,首先利用密码技术进行会话初始化验证,以确保通信双方的合法性的能力。其次,在通信过程中,能保证选用符合国家有关部门要求的密码算法对整个报文或会话过程进行加密。通信双方约定加密算法,对信息进行编码和解码。此外,应用软件中需设置通话超时和自动退出机制,即当通信双方中有一方在一段时间内未做任何响应,这表明可能存在通信异常情况,另一方能够自动结束会话,以免造成信息在通信过程中的泄露。
2.3安全审计
安全审计通过采集各种类型的日志数据,提供对日志的统一管理和查询,使用特定规则,对系统软件应用状态实时监视,生成安全分析报告。安全审计的应用,能够规范系统用户的软件应用行为,起到预防、追踪和震慑作用。安全审计应用要覆盖所有用户,记录应用系统重要的安全相关事件,包括重要用户行为、系统资源的异常使用和重要系统功能的执行等。记录包括事件的日期和时间、用户、事件类型、事件是否成功,及其他与审计相关的信息,并有能力依据安全策略及时报警和中断危险操作。此外,审计记录应受到妥善保护,避免受到未预期的删除、修改或覆盖等操作,可追溯到的记录应不少于一年。在日常审计的基础上,应通过分析审计记录,及时发现并封堵系统漏洞,提升系统安全强度,定位网络安全隐患的来源,举证系统使用过程中违法犯罪的法律、刑事责任。电子政务系统软件应用安全审计可结合网络审计、数据库审计、应用和运维日志审计进行,几乎全部需要定制开发。
2.4系统资源控制
电子政务系统的资源使用主要体现在CPU、内存、带宽等资源的使用上,在这个过程中,除了系统软件以外,应用软件也需要建立一组能够体现资源使用状况的指标,来判断系统资源是否能满足软件应用的正常运行要求,当系统资源相关性能降低到预先规定的最小值时,应能及时报警。并对资源使用的异常情况进行检测,及时发现资源使用中的安全隐患。系统资源应保证优先提供给重要、紧急的软件应用。因此,在资源控制的安全策略上应设定优先级,并根据优先级分配系统资源,从而确保对关键软件应用的支持。技术实现上设计用户登录系统时,软件为其分配与其权限相对应的连接资源和系统服务,为防止系统资源的重复分配,应禁止同一用户账号在同一时间内并发登录,并且,在用户登录后防止长时间非正常占用系统资源,而降低系统的性能或造成安全隐患,通常设计根据安全策略设置登录终端的操作超时锁定和鉴别失败锁定,并规定解锁或终止方式。同样,系统对发起业务的会话分配所用到的资源,也采用根据安全属性(用户身份、访问地址、时间范围等)允许或拒绝用户建立会话连接,对一个时间段内可能的并发会话连接数和单个用户的多重并发会话数量进行限制。在系统整体资源的使用上,对最大并发会话连接数进行限制。此外,对电子政务系统被删除的文件等的剩余信息,特别是涉及国家秘密、敏感信息的内容,一定要重点关注并加强安全保护。可采用下列技术实现保护:(1)采用先进的磁盘读写技术对磁盘的物理扇区进行多次反复的写操作,直到擦写过后的磁盘扇区内数据无法恢复;(2)根据不同的分区格式进行采用不同的数据销毁处理算法,对文件在磁盘上所有存放位置进行逐个清除,确保文件不会在磁盘上留下任何痕迹;(3)进行目录、剩余磁盘空间或整个磁盘的数据销毁,销毁后的目录、剩余磁盘空间或者整个磁盘不存在任何数据,无法通过软件技术手段恢复。
2.5软件代码安全
在电子政务系统应用软件开发之前,要制定应用程序代码编写安全规范,要求开发人员遵从规范编写代码。应用程序代码自身存在的漏洞被利用后可能会危害系统安全。因此,应对应用软件代码进行安全脆弱性分析,以帮助其不断改进完善,从而有效降低软件应用的安全风险。研发工作结束后,应及时对程序代码的规范性进行审查,以查找其设计缺陷及错误信息。代码审查一般根据需要列出所需资料清单,由应用软件使用方收集并提供相应的材料。代码测试人员与开发人员书面确认测试内容和过程,配置运行环境,对代码进行预编译操作,确认可执行使用。然后使用特定的测试工具进行代码的安全测试操作,对测试结果进行分析。对发现的问题进行风险分析和估算,制作软件缺陷、问题简表,撰写测试报告并交付开发方修改,并对已经整改的部分进行复测。值得注意的是,那些已经通过安全测试的代码,还需要运行在通过安全测试的支撑平台、编译环境中才能实现真正的安全运行。
2.6软件容错
电子政务系统中应用软件的高可用性是保障系统安全、平稳运行的基础。软件容错的原理是通过提供足够的冗余信息和算法程序,使系统在实际运行时能够及时发现错误,并能采取补救措施。对系统软件应用安全来说,应充分考虑到软件自身出现异常的可能性。软件在应用过程中,除设计对软件运行状态的监测外,当故障发生时能实时检测到故障状态并报警,防止软件异常的进一步蔓延,应具有自动保护能力,即当故障发生时能够自动保存当前所有状态。此外,操作人员对应用软件的操作可能会出现失误。因此,系统应对输入的数据、指令进行有效性检查,判断其是否合法、越权,并能及时进行纠正。关键功能应支持按照操作顺序进行功能性撤销,以避免因误操作而导致的严重后果。
三、结语
随着互联网的触角深入到生产生活中的各个层面,软件已经不像以前那样只是支持办公和家庭娱乐这两大主题了,而是成为现代商业的灵魂。软件安全问题主要围绕着软件漏洞和易被攻击脆弱点,它们都来自于软件的设计和实现。Internet催生了电子商务,移动互联网使得APP变得如火如荼,未来物联网也许可以将生活中的一切元素都纳入到通信网络中去。因此软件安全问题将成为计算机安全的核心,而非防火墙等网络硬件,或是诸如加密等手段。软件安全是一切计算机安全性问题的根源,如果软件行为出现异常,与之相关的可靠性、可用性等方面问题就会随之暴露。软件安全问题并不是互联网出现后才有的,只不过互联网是目前最容易攻击软件的途径罢了。
2软件安全的现状
2.1人们的认知
随着黑客攻击的新闻时常见诸媒体,人们对计算机安全问题有了一定认识。但不幸很多计算机安全人员和计算机教育培训人员都忽视了软件安全的问题。一味地推崇某种软件平台是安全的,单纯大力增加对网络安全硬件和软件的投入,这些做法是盲目甚至荒谬的。一切安全性都不是静态特性,也没有任何软件是绝对安全的。软件安全问题的关键节点是软件的设计。
2.2软件安全设计的先天不足
世界上知名的软件厂商并不是不了解软件安全设计安全性的重要性,而是商业模式让软件安全方面存在着先天不足。稍纵即逝的商业机会、敏捷的软件开发过程和短暂的软件开发周期使得安全性方面的设计在很多时候都是被舍弃的。随之而来的处理方式则是常见的penetrate-and-pach方法,即不停地补丁。这种做法从长远来看,其成本与作用远不及一开始就做好安全性的设计和审计。
3软件安全设计应引入风险管理
从项目管理的角度看,风险指损失或损害的可能性。软件项目涉及到的是:项目中可能发生的潜在问题和它们如何妨碍项目成功。风险管理则是对应软件项目生命周期内的风险的科学和艺术。软件安全性的设计与软件设计的其他一些质量性能是互相抵触的,例如冗余性、高效性。而软件开发过程中的风险管理与软件开发的诸如时间、范围、成本等因素也是相互抵触的。但是绝不能因为这些可能发生的抵触行为而放弃对安全性和风险管理的考虑,反而应该将软件安全性设计纳入到风险管理的范畴中去。事实表明,93%的失控项目都忽视了风险管理。
4软件安全设计风险管理的实施
目前国际上对软件安全方面的风险管理存在着一个共同的认知,那就是采用高质量的软件工程的方法论可以在一定程度上解决这方面的问题,欧美一些国家也在试图制定或修订相关的一些“通用准则”来指导软件安全性设计的实践。但是这只是从科学技术方面做出努力,我们可以学习借鉴。而在管理技术和艺术方面需要做出的努力则应该尝试本地化做法。完整的风险管理的过程应该包括以下几个环节:风险管理计划的编制、风险识别、风险定性分析、风险定量分析、风险应对计划编制和风险监督控制。将整个流程都走完的项目和企业都不多,一般来自于所谓的学院派。而时下大多数国内外企业的做法是将这个7个流程简化为谁来识别风险、谁来对风险负责这两个环节。原因则是上文所提到的先天不足所致。从技术上讲,风险管理的效益来自于潜在风险最小化和潜在回报的最大化。而这个技术的应用则一定需要经历风险定量分析的过程。在这个过程中,可以使用的主要技术是决策树分析、蒙特卡罗分析、PERT分析等等。这些技术都是建立在一定的数学和会计基础之上。而令人遗憾的是,很多决策者本身对这些技术的认知或理解欠缺,以至于会抵触这种方法。大多数做法是采用小团队开发小软件的做法,即采用访谈和敏感性分析来帮助风险定量分析。然而我们并不是要反对这种简化做法,只是一定不能在简化的做法之上再次简化或敷衍了事。首先要做的工作是做好需求管理,在建立一组需求输入的时候,一定要将安全性作为一个重要需求考虑进去。有一个比较好的方法是,在软件设计时采用螺旋模型,需求的输入可以在螺旋模型的各个生命周期中进行,而有关安全性的需求输入则最好是在最初的一个螺旋中进行。之后要做的工作是确定最大风险。不可避免的要使用风险定性和风险定量分析的各种技术和方法。这个工作一定要有软件设计师、项目决策者和用户的参与,采用头脑风暴和专家访谈是不错的选择。而这个工作恰恰是现实生活中中小企业乃至客户最容易忽略的。企业要考虑成本问题,而客户的参与往往难以落实,认为软件的设计和开发应该由软件公司负责,客户付款只关心最后软件是否可以使用。而一旦由于软件安全性问题造成了一定后果后将演变成各种纠缠不清的官司,这是企业和客户都不想看到的结果。
5结语
1.1计算机软件安全检测的流程
通常计算机软件安全检测的过程中只要有以下几个流程,首先是为了彻底全面的对计算机软件系统当中可能存在的缺陷予以充分的检测和了解,要对软件设计过程中最小的模块进行进行全面的测试,之后是要严格按照设计的标准和要求对组装的系统进行检测,此外还要对与之相关的体系机构进行全面的检查。其次就是要在做好了上述各项功能工作之后,还要对软件自身的有效性和功能性进行详细科学的检测,最后一点就是要对整个系统进行全面的检测,测试整个软件在各种环境下运行的安全性和可靠性。
1.2当前计算机软件安全检测的只要方法
首先是形式化的检测。形式化的安全监测实际上就是根据具体的要求来建立软件应有的数学模型,之后通过对应的标准化语言对其进行格式化的说明。形式化的安全监测通常有两种检测方法,一种是模型检测,一种是定量检测。其次就是在模型基础上的静态安全检测。模型安全监测一方面是通过软件行为和结构构建的一种方式,这样也就形成了一个可供测试的模型,这种模型在运行的过程中一方面可以在计算机上实现读取,在工作的过程中,比较常用的模型安全检测方法有两种,一种是有限状态机检测,一种是马尔科夫链检测、再次就是语法检测。语法检测实际上就是技术人员通过技术措施对软件在不同的输入条件下所产生的反应是否相同。四是基于故障注入的软件安全检测。故障注入的安全检测是应用故障分析树与故障数的最小割集来检测的。五是模糊测试和基于属性的测试。基于白盒的模糊测试较传统的模糊测试技术有很大进步,白盒模糊检测方法有效地结合了传统的模糊测试技术和动态测试用例检测技术的优点。六是混合检测技术。能有效地改善静态技术和动态技术检测存在的一些缺陷,从而更好地对计算机软件的安全进行检测。七是基于Web服务的检测技术。它是一种基于识别内容的分布式Web服务器技术。具有语言中立、互动操作性强等优点,能够将复杂的安全检测分解为子安全类型进行处理,以使其可以更有效地应对复杂的安全检测的需要。
2软件维护的主要类型
2.1改正性维护
改正性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。这方面的维护工作量要占整个维护工作量的17%~21%。所发现的错误有的不太重要,不影响系统的正常运行,其维护工作可随时进行:而有的错误非常重要,甚至影响整个系统的正常运行,其维护工作必须制定计划,进行修改,并且要进行复查和控制。
2.2适应性维护
适应性维护是指使用软件适应信息技术变化和管理需求变化而进行的修改。这方面的维护工作量占整个维护工作量的18%~25%。由于计算机硬件价格的不断下降,各类系统软件屡出不穷,人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求;企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样,有计划、有步骤地进行。
3提高软件的可维护性方法
3.1建立明确的软件质量目标
如果要一个可维护性的程序满足可理解的、可靠的、可测试的、可修改的、可移植的、效率高的和可使用的7个全部的要求,要付出很大的代价,甚至是不显示的。但是可理解性和可测试性以及可理解性和可修改性是相互促进的,而效率和可移植性以及效率和可修改性是相互抵触的。因此,要明确软件所追求的质量目标。
3.2使用先进的软件开发技术和工具
利用先进的软件开发技术能够大大提高软件质量和减少软件费用,并且稳定性好,容易修改、容易理解,易于测试和调试,因此可维护性好。
3.3建立明确的质量保证
最有效的方法就是质量保证检查,在软件开发的各个阶段以及软件维护中得到了广泛的应用。
4结束语
本站为第三方开放式学习交流平台,所有内容均为用户上传,仅供参考,不代表本站立场。若内容不实请联系在线客服删除,服务时间:8:00~21:00。