تصاحب Watchfire توسط IBM

صنعت امنیت بعد از دوران شروع به کار خودش کم کم وارد مرحله بلوغ شده است، غول های بزرگ تکنولوژی اطلاعاتی شروع به برنامه ریزی بلند مدت در مورد امنیت برنامه ها و کاهش ریسک مشتریانشان کرده اند. جدیدترین نمونه تصاحب Watchfire از سوی IBM است. طی تفاهم نامه ای که دیروز اعلام شد، با تصاحب Watchfire از طرف IBM و ترکیب محصولات آن با خانواده IBM’s Rational توسعه نرم افزارها با امنیت بیشتری ادامه خواهد یافت.

IBM to Acquire Watchfire to Help Customers Guard Against Online Security Attacks and Compliance Breaches.

چرخه حیات امنیت


چرخه حیات امنیت
(
Security Life Cycle) دارای نسخه ها و تعاریف مختلفی است،
که در نهایت هدف هر کدام نگهداری وضعیت امنیتی یک سیستم (این سیستم می تواند یک
سازمان، یک شبکه یا یک برنامه یکپارچه باشد.) در حالت مطلوب و آماده است. معروفترین
نوع چرخه حیات امنیت
(
SLC) که به طور کلی هر سیستمی را می تواند شامل شود،
شامل این ۴ وضعیت است:

   
۱-ارزیابی
    2-طراحی
    3-به کارگیری و پیاده سازی
    4-نگهداری

همانطور که
پیشتر ذکر شد، این چرخه امنیتی برای هر سیستمی قابل تعریف است، این سیستم می تواند
یک شبکه، یک مرکز داده و یا یک سازمان باشد. در اینجا به صورت مختصر، هر کدام از
این وضعیت ها را برای یک مرکز داده بررسی می کنیم. در این حالت اعضای این چرخه
امنیتی، شامل بستر اصلی شبکه، سرورها و رویه های کاری خواهند بود.

جریان
SLC یک پروسه ادامه دار و زنده است، در هر مرحله وضعیت کنونی و هدف
می بایست به صورت کامل مستندسازی شود و تمامی مستندات قابل اندازه گیری و مقایسه
پذیر ( ابعاد متریک و کمی) باشند. در هر مرحله، با استفاده از مقایسه هایی که انجام
خواهد شد، میزان پیشرفت و بهبود سیستم قابل گزارش خواهد بود.

۱-ارزیابی:
پروسه ممیزی، بازرسی، آزمایش و رسیدگی به آسیب پذیری ها از طریق تحلیل ریسک ها را
ارزیابی می گوییم. خروجی فاز ارزیابی، فهرستی از اجزای حیاتی سیستم و وضعیت ریسک
فعلی آسیب پذیری های شناخته شده و فهرست آن ها خواهد بود که به عنوان منبع اطلاعاتی
برای فاز طراحی مورد استفاده قرار خواهد گرفت. در یک مرکز داده، اجزای حیاتی شامل
سرورهایی با حساسیت بالا و بستر پشتیبان این سرور ها (شامل سوییچ ها، روترها،
فایروال
ها…) می باشد. آسیب پذیری های اصلی آن هایی خواهند بود که به این اجزای
حیاتی می توانند آسیب برسانند. برخی اوقات برای اطمینان از صحت و دقت اطلاعات،
ارزیابی شامل بررسی و آزمایش قسمت های مختلف سیستم خواهد بود. این بررسی ها
می‌تواند شامل

تست نفوذپذیری
سیستم باشد.

۲-طراحی:
پروسه به کارگیری سیاست نامه های امنیتی و رعایت نیازهای امنیتی مشخص شده در فاز
ارزیابی، به عنوان فاز طراحی امنیتی مطرح می‌شود. در این مرحله، برای رعایت توسعه
پذیری و مدیریت آسان تر سیستم، طراحی بر اساس یک فریم ورک توصیه می شود. این قالب
طراحی، می تواند از نوع آماده و یا تجربی باشد. در طراحی
مراکز داده،
استفاده از طراحی ماجولار بهترین روش برای دسته بندی امکانات و پاسخ گویی به نیازها
است.

۳-به کارگیری
و پیاده سازی
:عبارت است از پیاده سازی خروجی های فاز طراحی بر اساس نیازهای
مطرح شده و همچنین با توجه ویژه به ساختار اصلی شبکه. در این مرحله، یکپارچه سازی
سیاست نامه های امنیتی تهیه شده با امکانات و نیازهای موجود از حساسیت ویژه ای
برخوردار است. پیاده سازی زمانی قابل استفاده خواهد بود که تمامی اجزای مرکز داده
به درستی با یکدیگر ارتباط برقرار کنند.

۴-نگهداری:
پروسه نگهداری برنامه ها، شبکه و رویه های کاری بر اساس سیاست نامه های
امنیتی تهیه شده، با استفاده از

مانیتورینگ کل اجزای مرکز داده
بر اساس توصیه نامه ها و استانداردهای موجود
تنها راه تضمین حیات و پایداری کسب و کار در دراز مدت است. بهترین طراحی ها و دقیق
ترین پیاده سازی ها بدون استفاده از نگهداری صحیح در طول زمان با مشکلاتی مواجه
خواهند شد
.

گزارش حمله به DNS Root Server ها و اثر Anycast

افزایش حملاتی که در ابعاد بزرگ بستر اصلی اینترنت را هدف گرفته اند، موجب پدید آمدن راه کارهایی برای جلوگیری از خرابی ستون فقرات اصلی اینترنت شده است. یکی از این روش ها، استفاده از Anycast می باشد. به صورت مفید و مختصر یعنی مشخص کردن بهترین و نزدیک ترین مسیر برای یک بسته شبکه از دید توپولوژی مسیریابی (Routing) شبکه ! برای اطلاعات بیشتر مراجعه کنید به RFC 3258

این تکنولوژی در آخرین آزمایش واقعی خود توانست تاثیر منحصر به فردی برای مقابله با آخرین حمله به Root DNS Server ها که در اوخر فوریه ۲۰۰۷ اتفاق افتاد، نشان دهد. در این مورد مراجعه کنید به ICANN Releases Factsheet on Root DNS Attack ، همچنین سند Effect of anycast on K-root نیز می تواند اطلاعات دقیق تری ( در مورد حمله مارس ۲۰۰۵) در اختیار شما قرار دهد.

What can be done to reduce the risk of such attacks in future?
There are various measures aside from strengthening the root servers that will aid in defeating future attacks on the DNS.
In a March 2006 report on the DNS attack of the previous month, the SSAC made three recommendations for counteracting
such attacks:
۱٫ That those running DNS server adopt “source IP address verification”— i.e., that they improve and tighten existing systems.
۲٫ That root server operators—and those running country code top-level domains—draw up and publish their countermeasure policies, respond quickly to queries, and act quickly to add servers back into the system if the owner shows they have improved their security.
۳٫ ISPs should only accept DNS queries from trusted sources (i.e., their own customers) rather than allow anyone to use their servers.

نوشته های مربوط :

DNS Cache Poisoning

The DNS Attack: A Success Story for the Good Guys

March 2005 DNS Poisoning Summary

ویژگی امنیتی Cisco IOS

Cisco IOS علاوه بر نقش کنترل کننده حیاتی بسیاری از شبکه های مهم، می تواند نقش مهم و به سزایی در حفظ امنیت شبکه ها و سیستم های اطلاعاتی داشته باشد. علاوه بر نسخه های امنیتی IOS برخی از ویژگی ها در نسخه های عادی نیز قابل استفاده هستند. در اینجا به چند مورد از این ویژگی ها اشاره می کنیم.

  • Class-Based Access Control یا CBAC

  • Port-to-Address Mapping یا PAM

  • Authentication Proxy

  • TCP Intercept

  • Intrusion Prevention

  • AutoSecure

استاندارد های امنیتی کاربردی

با استفاده از قالب های مختلف XML و استاندارد سازی فرمت تبادل اطلاعات در برنامه/روش های امنیتی مختلف، امکان ایجاد یکپارچگی در نتایج فراهم می شود. این یکپارچگی علاوه بر ایجاد سهولت در ترکیب سامانه های مختلف، امکان توسعه سیستم های جامع پایش امنیت را آسان تر خواهد کرد. به این مجموعه که بیشتر در مورد سازمان دهی آسیب پذیری ها و رویدادهای امنیتی است توجه کنید:

Application Security Standards

  • Common Intrusion Detection Signatures Standard (CIDSS)
  • Common Vulnerabilities and Exposures (CVE)
  • DMTF Alert Standard Format Specification (ASF)
  • IETF Incident Object Description and Exchange Format (IODEF)
  • IETF Intrusion Detection Exchange Format (IDMEF)
  • OASIS Application Vulnerability Description Language TC (AVDL)
  • OASIS Web Application Security TC (WAS)
  • OpenSec Advisory and Notification Markup Language (ANML)
  • Open Vulnerability Assessment Language (OVAL)
  • Open Web Application Security Project (OWASP)
  • VulnXML Project: A Web Application Security Vulnerability Description Language

سیستم های ردیابی و کشف نفوذ توزیع شده – dIDS

سیستم های ردیابی و کشف نفوذ توزیع شده که با dIDS از آن یاد می کنیم،از چندین IDS در یک شبکه بزرگ تشکیل شده اند. تمامی این Intrusion Detection System ها، در ارتباط با یدیگر هستند و یا به وسیله یک سیستم (شاید یک سرور) مرکزی در حال پایش شبکه، تحلیل رویدادها و جمع آوری اطلاعات حمله های شناسایی شده، می باشند. این ترکیب برای جمع آوری اطلاعات امکان ایجاد یک دید وسیع برای تیم امنیتی/نگهدارنده شبکه در مورد وقایعی که در هر لحظه در حال جریان است را فراهم می کند.

یک distributed IDS به سازمان ها و اپراتورهای شبکه اجازه می دهد تا به صورت موثر و مستند منابع شبکه ای و سازمانی خود را تحت کنترل قرار دهند و در صورت نیاز به سرعت اطلاعات مورد نیاز را از سیستم بیرون بکشند. برای آشنایی بیشتر مقاله زیر را بخوانید:

An Introduction To Distributed Intrusion Detection Systems

Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.

تبادل اطلاعات بین IDS ها در سه گونه تقسیم بندی می شود. دسته اول محصولاتی که برای dIDS طراحی شده اند و با استفاده agentهای مختلف در نقاط مختلف شبکه اطلاعات را برای سرور کنترلی IDS ارسال می کنند. دسته دوم محصولاتی که شامل IDS هایی از یک دسته هستند و لاگ فایل های خود را در یک محل متمرکز ذخیره می کنند و مانند دسته اول ادامه کار می دهند. و بالاخره دسته سوم که شامل IDS ها و IPS های (به طور کلی آن ها را sensor خطاب می کنیم.) مختلف از مارک های متفاوتی هستند که به وسیله ابزار های مدیریت سیستم های امنیتی لاگ فایل ها را ذخیره و پردازش می کنند. استاندارد تبادل اطلاعات در سنسور ها، در قالب یک پیش نویس استاندارد IETF در حال شکل گیری است.

The Intrusion Detection Message Exchange Format (IDMEF) is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they deem suspicious. The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation.

به دو علت پروژه های کمی در مورد dIDS هم اکنون وجود دارد. اولین مورد عدم درک نیاز به چنین سیستمی در بخش تجاری و صنعتی و دلیل دوم نو بودن چنین ترکیبی است. همانطور که پیشتر گفتم، IDMEF هنوز به حالت استاندارد در نیامده است. البته جایگزینی این سیستم به وسیله سیستم های یکپارچه مدیریت امنیت گران قیمت نیز دلیل دیگری در کم بودن پروژه ها است. تعدادی از این پروژه ها را در freshmeat ببینید. بدنیست نگاهی هم به پروژه رو به پیشرفت Prelude Hybrid IDS ( حداقل What is Prelude Hybrid IDS را بخوانید.) بندازید.

* این مطلب مقدمه ای است برای سری نوشته های امنیت در عمق که در Secure2S بیشتر در مورد آن ها خواهید خواند. لطفا نظرات و پیشنهادات خود را در میان بگذارید. مجموعه نوشته های امنیت در عمق، تلاش خواهد کرد تا به امنیت در شبکه های بزرگ و تجاری و همچنین نکات امنیتی که کمتر به آن ها پرداخته می شود بپردازد.

EAL – Evaluation assurance level

Evaluation assurance level – به اختصار EAL – مجموعه ای از هفت قرار داد است تا نیازهای CC – Common Criteria – را بر آورده کند.بیشتر این استاندارد ها برای استفاده مشتریان  دولتی و نظامی لازم است. هر کدم از این هفت سطح فراهم آورنده میزان اعتماد و اطمینان پذیری یک محصول است.

به اختصار می توان این ۷ سطح را در غالب جدول زیر بیان کرد :

EAL 0

Inadequate Assurance

EAL 1

Functionally Tested. Provides
analysis of the security functions, using a functional and interface
specification of the TOE, to understand the security behaviour. The analysis
is supported by independent testing of the security functions.

EAL 2

Structurally Tested. Anaysis of
the security functions using a functional and interface specification and
the high level design of the subsystems of the TOE. Independent testing of
the security functions, evidence of developer “black box” testing, and
evidence of a development search for obvious vulnerabilities.

EAL 3

Methodically Tested and
Checked. The analysis is supported by “grey box” testing, selective
independent confirmation of the developer test results, and evidence of a
developer search for obvious vulnerablitities. Development environment
controls and TOE configuration management are also required.

EAL 4

Methodically Designed, Tested
and Reviewed. Analysis is supported by the low-level design of the modules
of the TOE, and a subset of the implementation. Testing is supported by an
independent search for obvious vulnerabilities. Development controls are
supported by a life-cycle model, identification of tools, and automated
configuration management.

EAL 5

Semiformally Designed and
Tested. Analysis includes all of the implementation. Assurance is
supplemented by a formal model and a semiformal presentation of the
functional specification and high level design, and a semiformal
demonstration of correspondence. The search for vulnerabilities must ensure
relative resistance to penetration attack. Covert channel analysis and
modular design are also required.

EAL 6

Semiformally Verified Design
and Tested. Analysis is supported by a modular and layered approach to
design, and a structured presentation of the implementation. The independent
search for vulnerabilities must ensure high resistance to penetration
attack. The search for covert channels must be systematic. Development
environment and configuration management controls are further strengthened.

EAL 7

Formally Verified Design and
Tested. The formal model is supplemented by a formal presentation of the
functional specification and high level design showing correspondence.
Evidence of developer “white box” testing and complete independent
confirmation of developer test results are required. Complexity of the
design must be minimised.

می توانید تفصیلات کامل هر سطح را در این جا بخوانید : Evaluation assurance levels

اطلاعات بیشتری را هم در این سایت ها پیدا خواهید کرد: www.cesg.gov.uk | Common Criteria Assurance Levels | The National Information Assurance  Partnership

علت این نوشته هم خبری بود که حاکی از تلاش Red Hat برای گرفتن EAL 2 برای محصول Red Hat Enterprise Linux می داد.می توانید اصل خبر را در اینجا ببینید.

نکته ای که جالب به نظر می رسد این است که برخی از نسخه های ویندوز EAL4 را کسب کرده اند و کمپانی Red Hat به تازگی توانسته است با کمک از Oracle به EAL 2 دست پیدا کند.آیا این چیز ها هم با پول خریداری می شود؟ شاید هر چه قدر مبلغ بیشتری پرداخت شود سطح امنیتی بالاتری کسب شود ، به این جمله توجه کنید :

Security is not a destination; it’s a way of travelling. It’s not a product; it’s a procedure.