其一是驱动程序的编写不同于普通用户态程序的写作，其难度很大。写用户态程序时你需要的仅仅就是调用一些熟知的API函数来完成特定的目的，比如打开文件你只需调用CreateFile就可以了；但在驱动程序中你将无法使用熟悉的CreateFile。在NT/2000下你可以使用ZwCreateFile或NtCreateFile（native API），但这些函数通常会要求运行在某个IRQL（中断请求级）上，如果你对如中断请求级，延迟/异步过程调用，非分页/分页内存等概念不是特别清楚，那么你写的驱动将很容易导致蓝屏死机（BSOD），Ring0下的异常将往往导致系统崩溃，因为它对于系统总是被信任的，所以没有相应处理代码去捕获这个异常。在NT下对KeBugCheckEx的调用将导致蓝屏的出现，接着系统将进行转储并随后重启。另外驱动程序的调试不如用户态程序那样方便，用象VC++那样的调试器是不行的，你必须使用系统级调试器，如softice,kd,trw等。

其二是驱动程序与ring3下客户程序的通信问题。这个问题的提出是很自然的，试想当驱动程序截获到某个访问网络请求时，它必须通知位于ring3下的查毒模块检查访问网络的合法性，随后查毒模块还需将查毒的结果通过某种方式传给ring0下的监控程序，最后驱动程序根据返回的结果决定请求是否被允许。这里面显然存在一个双向的通信过程。写过驱动程序的人都知道一个可以用来向驱动程序发送设备I/O控制信息的API调用DeviceIoControl，它的接口在MSDN中可以找到，但它是单向的，即ring3下客户程序可以通过调用DeviceIoControl将某些信息传给ring0下的监控程序但反过来不行。既然无法找到一个现成的函数实现从ring0下的监控程序到ring3下客户程序的通信，则我们必须采用迂回的办法来间接做到这一点。为此我们必须引入异步过程调用（APC）和事件对象的概念，它们就是实现特权级间唤醒的关键所在。现在先简单介绍一下这两个概念。异步过程调用是一种系统用来当条件合适时在某个特定线程的上下文中执行一个过程的机制。当向一个线程的APC队列排队一个APC时，系统将发出一个软件中断，当下一次线程被调度时，APC函数将得以运行。APC分成两种：系统创建的APC称为内核模式APC，由应用程序创建的APC称为用户模式APC。另外只有当线程处于可报警（alertable）状态时才能运行一个APC。比如调用一个异步模式的ReadFileEx时可以指定一个用户自定义的回调函数FileIOCompletionRoutine，当异步的I/O操作完成或被取消并且线程处于可报警状态时函数被调用，这就是APC的典型用法。Kernel32.dll中导出的QueueUserAPC函数可以向指定线程的队列中增加一个APC对象，因为我们写的是驱动程序，这并不是我们要的那个函数。很幸运的是在Vwin32.vxd中导出了一个同名函数QueueUserAPC，监控程序拦截到一个文件打开请求后，它马上调用这个服务排队一个ring3下客户程序中需要被唤醒的函数的APC，这个函数将在不久客户程序被调度时被调用。这种APC唤醒法适用于WIN9X，在WINNT/2000下我们将使用全局共享的事件和信号量对象来解决互相唤醒问题。NT/2000版监控程序中我们将利用KeReleaseSemaphore来唤醒一个在ring3下客户程序中等待的线程。目前不少反病毒软件已将驱动使用的查毒模块移到ring0，即如其所宣传的“主动与操作系统无缝连接”，这样做省却了通信的消耗，但把查毒模块写成驱动形式也同时会带来一些麻烦，如不能调用大量熟知的API，不能与用户实时交互，所以我们还是选择剖析传统的反病毒软件的监控程序。

其三是驱动程序所占用资源问题。如果由于监控程序频繁地拦截访问网络操作而使系统性能下降过多，则这样的程序是没有其存在的价值的。一个成功的反木马软件的监控程序做彻底的剖析，其中就包含有分析其用以提高自身性能的技巧的部分，如设置黑名单记录，内置文件类型过滤，设置等待超时等。
IP/URL过滤
一旦应用流量呈明文格式，就必须检测HTTP请求的URL部分，寻找恶意攻击的迹象，譬如可疑的统一代码编码（unicode encoding）。对URL过滤采用基于特征的方案，仅仅寻找匹配定期更新的特征、过滤掉与已知攻击如红色代码和尼姆达有关的URL，这是远远不够的。这就需要一种方案不仅能检查RUL，还能检查请求的其余部分。其实，如果把应用响应考虑进来，可以大大提高检测攻击的准确性。虽然URL过滤是一项重要的操作，可以阻止通常的脚本少年类型的攻击。
请求分析
全面的请求分析技术比单单采用URL过滤来得有效，可以防止Web服务器层的跨站脚本执行（cross-site scripting）漏洞和其它漏洞。全面的请求分析使URL过滤更进了一步：可以确保请求符合要求、遵守标准的HTTP规范，同时确保单个的请求部分在合理的大小限制范围之内。这项技术对防止缓冲器溢出攻击非常有效。然而，请求分析仍是一项无状态技术。它只能检测当前请求。正如我们所知道的那样，记住以前的行为能够获得极有意义的分析，同时获得更深层的保护。
访问网络进程跟踪
下一个技术就是访问网络进程跟踪。这是防火墙技术的最基本部分：跟踪访问网络进程，判断进程访问网络的合法性，进行有效拦截。这项功能通常借助于TDI层的网络数据拦截，得到操作网络数据报的进程的详细信息加以实现。跟踪进程访问的请求，能够对大部分病毒进程的进行检查。这样就能有效防御。对于一些注入式木马多数安全软件采用Hook CreateRemoteProcess等API函数进行防范，比较强的一些安全软件能够进行模块分离。
响应模式匹配
响应模式匹配为应用提供了更全面的保护：它不仅检查提交至Web服务器的请求，还检查Web服务器生成的响应。它能极其有效地防止网站受毁损，或者更确切地说，防止已毁损网站被浏览。对响应里面的模式进行匹配相当于在请求端对URL进行过滤。响应模式匹配分三个级别。防毁损工作由应用防火墙来进行，它对站点上的静态内容进行数字签名。如果发现内容离开Web服务器后出现了改动，防火墙就会用原始内容取代已毁损页面。至于对付敏感信息泄露方面，应用防火墙会监控响应，寻找可能表明服务器有问题的模式，譬如一长串Java异常符。如果发现这类模式，防火墙就会把它们从响应当中剔除，或者干脆封阻响应。
采用“停走”字（‘stop and go’word）的方案会寻找必须出现或不得出现在应用生成的响应里面的预定义通用模式。譬如说，可以要求应用提供的每个页面都要有版权声明。
行为建模
行为建模有时称为积极的安全模型或“白名单”（white list）安全，它是唯一能够防御最棘手的应用漏洞——零时间漏洞的保护机制。零时间漏洞是指未写入文档或“还不知道”的攻击。对付这类攻击的唯一机制就是只允许已知是良好行为的行为，其它行为一律禁止。这项技术要求对应用行为进行建模，这反过来就要求全面分析提交至应用的每个请求的每次响应，目的在于识别页面上的行为元素，譬如表单域、按钮和超文本链接。这种级别的分析可以发现恶意表单域及隐藏表单域操纵类型的漏洞，同时对允许用户访问的URL实行极其严格的监控。行为建模是唯一能够有效对付全部16种应用漏洞的技术。行为建模是一种很好的概念，但其功效往往受到自身严格性的限制。
某些情况譬如大量使用JavaScript或者应用故意偏离行为模型都会导致行为建模犯错，从而引发误报，拒绝合理用户访问应用。行为建模要发挥作用，就需要一定程度的人为干预，以提高安全模型的准确性。行为自动预测又叫规则自动生成或应用学习，严格说来不是流量检测技术，而是一种元检测（meta-inspection）技术，它能够分析流量、建立行为模型，并且借助于各种关联技术生成应用于行为模型的一套规则，以提高精确度。行为建模的优点在于短时间学习应用之后能够自动配置。保护端口80是安全人员面临的最重大也是最重要的挑战之一。所幸的是，如今已出现了解决这一问题的创新方案，而且在不断完善。如果在分层安全基础设施里面集成了能够封阻16类应用漏洞的应用防火墙，你就可以解决应用安全这一难题。