Re: Apple: Patch Management

[Apple CA via dev-security-policy]

On Monday, December 9, 2019 at 2:03:20 PM UTC-8, Matt Palmer wrote:
> On Fri, Dec 06, 2019 at 07:08:46PM -0800, Apple CA via dev-security-policy 
> wrote:
> > On Saturday, November 23, 2019 at 3:28:10 PM UTC-8, Matt Palmer wrote:
> > > [aside: this is how incident reports should be done, IMHO]
> > > 
> > > On Fri, Nov 22, 2019 at 07:23:27PM -0800, Apple CA via 
> > > dev-security-policy wrote:
> > > > We did not have an accurate understanding of how the vulnerability 
> > > > scanner
> > > > worked.  Our understanding of its capabilities lead us to believe it was
> > > > scanning and detecting vulnerabilities in EJBCA.
> > > 
> > > There's a reasonable chance that other CAs may have a similar situation, 
> > > so
> > > I think it's worth digging deeper into the root causes here.  Can you 
> > > expand
> > > on how this misunderstanding regarding the vulnerability scanner came to
> > > pass?  What was the information on which you were relying when you came to
> > > the understanding of the vulnerability scanner's capabilities?  Were you
> > > misled by the vendor marketing or technical documentation, or was it an
> > > Apple-internal assessment that came to an inaccurate conclution?  Or
> > > "other"?
> > 
> > In order to identify vulnerabilities, the vulnerability scanner (1)
> > attempts to identify/profile software listening on ports and (2) compares
> > software versions against public CVEs and proprietary data sources.  EJBCA
> > is not broadly used software, and the vulnerability scanner did not have
> > custom EJBCA detection logic.  Upon our deeper investigation, we
> > discovered that it (1) only scans the HTTP service and not the EJBCA
> > software, which we would consider insufficient on its own and (2) is not
> > as effective at flagging vulnerabilities in EJBCA because CVEs are not
> > published by EJBCA.  We don’t feel we were mislead by the vendor.
> 
> Thanks for clarifying how the security scanning software worked; that's
> useful.  I'm not confident that we've determined any root causes for the
> failure, though, especially things that other CAs in the ecosystem can learn
> from.  I'll try a different phrasing, which will hopefully provide more
> clarity as to what I'm trying to achieve:
> 
> What specific, actionable items would you recommend all CAs undertake to
> remove or mitigate the risk of this, or a substantially similar, problem
> occurring in their environment?
> 
> > CVEs are not published by EJBCA.
> 
> Does anyone else feel that this is a really, really, *really* bad idea?  The
> CVE system, whilst far from perfect, seems to be the agreed upon medium for
> managing these types of issues, and it disappoints me that EJBCA would
> appear to be "opting out" of it.  Should discussions with EJBCA, either from
> their customers or the wider community, be initiated?
> 
> - Matt

The actions we took are as follows:
* We revisited the functionality of the vulnerability scanner, its ability to 
identify vulnerabilities in the CA software, and questioned our previous 
assumptions about how it functions.
* We revisited the support and patch management notification mechanisms 
employed by the CA software vendor.
* We revisited the Network and Certificate System Security Requirements to 
ensure appropriate coverage for the relevant requirements.
* We no longer rely on the vulnerability scanner as a key control to detect 
security vulnerabilities with EJBCA.
* We made our review of software releases and decisions about upgrading a key 
control.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CATCert Root Inclusion Request

[marshsarah475--- via dev-security-policy]

Ok do I'm not sure if it's appropriate that I message on this, I'm just a 
citizen, but one who has personally seen and noticed fake certificates and most 
definitely ones that were "man in the middle attack" certificates. I know these 
are old discussions do I'm assuming by now you all have seen the flat out bogus 
certificates that are clearly serious to the point that I know for a fact 
caused many security breeches. Now, like I said I'm no expert, but technically 
I'm getting all of this and figured out what certificates were the past year 
and noticed a good amount that were empty in the field , negative oreven no 
number at all or out of date , and duplicated. Now, this is my question. Has 
the teknotronic certifica still dealing havoc, or is someone doing something 
about it? I find it amazing that I'm understanding this whole conversation 
which makes me realize further that I definitely need to start my cyber 
security degree asap. I personally have seen the havok that these certificates 
can do when they aren't ligitimate. This stuff is like my passion I see and 
understand how important this all is in order to keep governments safe and top 
secret information, secret. Please give me some information on what is bring 
done and what I can do as far as schooling, (cyber security degree?) In order 
to do this kind of work. Like I said, I believe it's so important and might be 
one of the most important things going on with this technology that we have 
now. Thank you and sorry if I am innapropriate in writing this, but I'd love to 
hear from experts on what has been done and maybe even understand why I had 155 
roots on my last phone that half were not legitimate. Maybe it would help me 
either validate my fears and help to put it to rest or even completely make me 
feel more safe knowing that someone is aware, watching and atleast trying to 
sqaush what they can of it. Thank you I look forward to a response from someone 
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy