<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: [Chinese]NIST推出通用配置打分系统CCSS草案</title>
	<atom:link href="http://sbin.cn/blog/2008/06/09/nist-ccss/feed/" rel="self" type="application/rss+xml" />
	<link>http://sbin.cn/blog/2008/06/09/nist-ccss/</link>
	<description>Technologies and comments on cloud and telecom security, bridging China and the world!</description>
	<lastBuildDate>Mon, 19 Sep 2011 01:16:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Richard</title>
		<link>http://sbin.cn/blog/2008/06/09/nist-ccss/comment-page-1/#comment-33150</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Tue, 10 Jun 2008 14:16:30 +0000</pubDate>
		<guid isPermaLink="false">http://sbin.cn/blog/?p=395#comment-33150</guid>
		<description>下面是在SecurityMetrics的邮件列表中William Bell的一个回复，很有趣：
Some things that came to mind while reading this early draft:

1.) Attempting to integrate environmental support and mitigating circumstances, like with the CVSS is going to be tricky. There are two sides to this issue. Not including this support, will render the metrics ineffective due to the high probability that some type of mitigating circumstances or configuration may exist. On the other side by allowing super customization of the metrics you could end up with dirty information that takes a long time to collect and assess.

2.) It is proposed that vendors create the base metrics for a specific product configuration. I am not so sure that this is the best idea as it most often run counter to the main objective of the creation entity ( aka. Selling the crap out of their operating system…ahem MS ). I would not be opposed to their participation in the creation of these base metrics, due to the knowledge they possess over the system being scored.

3.) In the area of access complexity I am not sure that requiring the attacking party to have elevated privileges would be considered a HIGH level condition for active exploitation. I imagine this should most probably be chucked in with requiring some user level access, as the pervasive use of administrator privileges in today’s world often leaves little distinction between the two.

4.) The whole section regarding authentication is a bit foolhardy. In my opinion deciding to disregard the complexity of the authentication is a copout. The author is effectively saying we are going to treat 2 username/password authentications and other methods of multi-factor authentications the same. I am sure we can all agree that they are not. I would propose that the Multiple(M) metric be reserved for two factor authentication only. ( I decided to just ignore this as it almost made me fall out of my chair .. “Exploiting the weakness requires that the exploiter authenticate two or more times, even if the same credentials are used each time” )

I haven’t had time to evaluate the scoring system as of yet. If anything jumps out, I’ll be sure to comment.</description>
		<content:encoded><![CDATA[<p>下面是在SecurityMetrics的邮件列表中William Bell的一个回复，很有趣：<br />
Some things that came to mind while reading this early draft:</p>
<p>1.) Attempting to integrate environmental support and mitigating circumstances, like with the CVSS is going to be tricky. There are two sides to this issue. Not including this support, will render the metrics ineffective due to the high probability that some type of mitigating circumstances or configuration may exist. On the other side by allowing super customization of the metrics you could end up with dirty information that takes a long time to collect and assess.</p>
<p>2.) It is proposed that vendors create the base metrics for a specific product configuration. I am not so sure that this is the best idea as it most often run counter to the main objective of the creation entity ( aka. Selling the crap out of their operating system…ahem MS ). I would not be opposed to their participation in the creation of these base metrics, due to the knowledge they possess over the system being scored.</p>
<p>3.) In the area of access complexity I am not sure that requiring the attacking party to have elevated privileges would be considered a HIGH level condition for active exploitation. I imagine this should most probably be chucked in with requiring some user level access, as the pervasive use of administrator privileges in today’s world often leaves little distinction between the two.</p>
<p>4.) The whole section regarding authentication is a bit foolhardy. In my opinion deciding to disregard the complexity of the authentication is a copout. The author is effectively saying we are going to treat 2 username/password authentications and other methods of multi-factor authentications the same. I am sure we can all agree that they are not. I would propose that the Multiple(M) metric be reserved for two factor authentication only. ( I decided to just ignore this as it almost made me fall out of my chair .. “Exploiting the weakness requires that the exploiter authenticate two or more times, even if the same credentials are used each time” )</p>
<p>I haven’t had time to evaluate the scoring system as of yet. If anything jumps out, I’ll be sure to comment.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

